Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-40271 (GCVE-0-2025-40271)
Vulnerability from cvelistv5 – Published: 2025-12-06 21:50 – Updated: 2026-08-05 12:09| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
710585d4922fd315f2cada8fbe550ae8ed23e994 , < 1d1596d68a6f11d28f677eedf6cf5b17dbfeb491
(git)
Affected: 710585d4922fd315f2cada8fbe550ae8ed23e994 , < c81d0385500446efe48c305bbb83d47f2ae23a50 (git) Affected: 710585d4922fd315f2cada8fbe550ae8ed23e994 , < 4cba73c4c89219beef7685a47374bf88b1022369 (git) Affected: 710585d4922fd315f2cada8fbe550ae8ed23e994 , < 6f2482745e510ae1dacc9b090194b9c5f918d774 (git) Affected: 710585d4922fd315f2cada8fbe550ae8ed23e994 , < 67272c11f379d9aa5e0f6b16286b9d89b3f76046 (git) Affected: 710585d4922fd315f2cada8fbe550ae8ed23e994 , < 623bb26127fb581a741e880e1e1a47d79aecb6f8 (git) Affected: 710585d4922fd315f2cada8fbe550ae8ed23e994 , < 03de7ff197a3d0e17d0d5c58fdac99a63cba8110 (git) Affected: 710585d4922fd315f2cada8fbe550ae8ed23e994 , < 895b4c0c79b092d732544011c3cecaf7322c36a1 (git) |
guessed | |
| Linux | Linux |
Affected:
3.19
Unaffected: 0 , < 3.19 (semver) Unaffected: 5.4.302 , ≤ 5.4.* (semver) Unaffected: 5.10.247 , ≤ 5.10.* (semver) Unaffected: 5.15.197 , ≤ 5.15.* (semver) Unaffected: 6.1.159 , ≤ 6.1.* (semver) Unaffected: 6.6.117 , ≤ 6.6.* (semver) Unaffected: 6.12.59 , ≤ 6.12.* (semver) Unaffected: 6.17.9 , ≤ 6.17.* (semver) Unaffected: 6.18 , ≤ * (original_commit_for_fix) |
guessed | |
| Siemens | RUGGEDCOM RST2428P |
Affected:
0 , < V4.0
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"affected": [
{
"defaultStatus": "unknown",
"product": "RUGGEDCOM RST2428P",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V4.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-02T13:00:17.378Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
}
],
"x_adpType": "supplier"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-40271",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T19:37:49.226666Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-16T19:37:59.970Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/proc/generic.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1d1596d68a6f11d28f677eedf6cf5b17dbfeb491",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "c81d0385500446efe48c305bbb83d47f2ae23a50",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "4cba73c4c89219beef7685a47374bf88b1022369",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "6f2482745e510ae1dacc9b090194b9c5f918d774",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "67272c11f379d9aa5e0f6b16286b9d89b3f76046",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "623bb26127fb581a741e880e1e1a47d79aecb6f8",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "03de7ff197a3d0e17d0d5c58fdac99a63cba8110",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "895b4c0c79b092d732544011c3cecaf7322c36a1",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/proc/generic.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.19"
},
{
"lessThan": "3.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.302",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.247",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.197",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.159",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.117",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.59",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.302",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.247",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.197",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.159",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.117",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.59",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.9",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "3.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u003edev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026proc_subdir_lock);\n [time window] | rb_erase(\u0026root-\u003esubdir_node, \u0026parent-\u003esubdir);\n | write_unlock(\u0026proc_subdir_lock);\n read_lock(\u0026proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)"
}
],
"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 triggered entirely through local syscalls \u2014 `getdents64(2)` on a procfs directory racing against `unshare(2)`/rtnetlink operations that remove `/proc` entries. No network or remote-peer data is involved.\nAC:L - The attacker owns both sides of the race: one thread iterates `/proc/self/net/dev_snmp6` while another spins netdevice rename/unregister to erase entries, and the `dir_emit()` window can be stretched arbitrarily by backing the `getdents64` buffer with userfaultfd or FUSE so the reader stalls in `copy_to_user` while the neighbour pde is freed and the slab groomed. The sequence is unbounded and retryable.\nPR:L - Reading `/proc/self/net/dev_snmp6` requires no privilege at all, and the removal side needs only `CAP_NET_ADMIN` inside an attacker-created user+network namespace (`unshare -Urn`), which any unprivileged user obtains on default distro configurations. No real root in the init namespace is needed.\nUI:N - The attacker drives both the directory iteration and the proc-entry removal from its own threads; no victim action or cooperation is required.\nS:U - The corruption is confined to kernel heap objects managed by the same kernel security authority; there is no VM, IOMMU, or hypervisor boundary crossed.\nC:H - `dir_emit(ctx, de-\u003ename, de-\u003enamelen, ...)` reads the `char *name` pointer and `u8 namelen` out of the freed `proc_dir_entry` and copies up to 255 bytes from that pointer directly into the user\u0027s dirent buffer, giving a repeatable arbitrary-kernel-memory read into userspace once the slab object is reclaimed with attacker-influenced content.\nI:H - The use-after-free yields `refcount_inc()`/`refcount_dec_and_test()` on freed memory plus `pde_free()` performing `kfree(pde-\u003edata)`/`kfree(pde-\u003ename)` on pointers read from the reallocated object, providing arbitrary-free and heap-corruption primitives that are a standard basis for local privilege escalation.\nA:H - Dereferencing stale rbtree links into freed slab memory reliably produces a kernel oops/panic (as observed under stress-ng with getdents+tun), and the race can be re-run indefinitely to crash the system on demand."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:09:04.518Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/1d1596d68a6f11d28f677eedf6cf5b17dbfeb491"
},
{
"url": "https://git.kernel.org/stable/c/c81d0385500446efe48c305bbb83d47f2ae23a50"
},
{
"url": "https://git.kernel.org/stable/c/4cba73c4c89219beef7685a47374bf88b1022369"
},
{
"url": "https://git.kernel.org/stable/c/6f2482745e510ae1dacc9b090194b9c5f918d774"
},
{
"url": "https://git.kernel.org/stable/c/67272c11f379d9aa5e0f6b16286b9d89b3f76046"
},
{
"url": "https://git.kernel.org/stable/c/623bb26127fb581a741e880e1e1a47d79aecb6f8"
},
{
"url": "https://git.kernel.org/stable/c/03de7ff197a3d0e17d0d5c58fdac99a63cba8110"
},
{
"url": "https://git.kernel.org/stable/c/895b4c0c79b092d732544011c3cecaf7322c36a1"
}
],
"title": "fs/proc: fix uaf in proc_readdir_de()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-40271",
"datePublished": "2025-12-06T21:50:53.266Z",
"dateReserved": "2025-04-16T07:20:57.183Z",
"dateUpdated": "2026-08-05T12:09:04.518Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-40271",
"date": "2026-09-18",
"epss": "0.00455",
"percentile": "0.38824"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/proc/generic.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1d1596d68a6f11d28f677eedf6cf5b17dbfeb491",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "c81d0385500446efe48c305bbb83d47f2ae23a50",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "4cba73c4c89219beef7685a47374bf88b1022369",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "6f2482745e510ae1dacc9b090194b9c5f918d774",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "67272c11f379d9aa5e0f6b16286b9d89b3f76046",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "623bb26127fb581a741e880e1e1a47d79aecb6f8",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "03de7ff197a3d0e17d0d5c58fdac99a63cba8110",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "895b4c0c79b092d732544011c3cecaf7322c36a1",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/proc/generic.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.19"
},
{
"lessThan": "3.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.302",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.247",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.197",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.159",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.117",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.59",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "RUGGEDCOM RST2428P",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V4.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u003edev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026proc_subdir_lock);\n [time window] | rb_erase(\u0026root-\u003esubdir_node, \u0026parent-\u003esubdir);\n | write_unlock(\u0026proc_subdir_lock);\n read_lock(\u0026proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)"
}
],
"id": "CVE-2025-40271",
"lastModified": "2026-07-30T06:24:24.733",
"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"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-40271",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T19:37:49.226666Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-12-06T22:15:54.737",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/03de7ff197a3d0e17d0d5c58fdac99a63cba8110"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1d1596d68a6f11d28f677eedf6cf5b17dbfeb491"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4cba73c4c89219beef7685a47374bf88b1022369"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/623bb26127fb581a741e880e1e1a47d79aecb6f8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/67272c11f379d9aa5e0f6b16286b9d89b3f76046"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6f2482745e510ae1dacc9b090194b9c5f918d774"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/895b4c0c79b092d732544011c3cecaf7322c36a1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c81d0385500446efe48c305bbb83d47f2ae23a50"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-07-30T08:37:53+00:00",
"cve": "CVE-2025-40271",
"id": "CVE-2025-40271",
"initial_release_date": "2025-12-06T00:00:00+00:00",
"product_status:fixed": "2410",
"product_status:known_affected": "22",
"product_status:known_not_affected": "20",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: Linux kernel: Use-after-free in proc_readdir_de() can lead to privilege escalation or denial of service.",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-40271.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-08-28T16:54:22Z",
"cve": "CVE-2025-40271",
"id": "CVE-2025-40271",
"initial_release_date": "2025-12-08T00:23:21Z",
"product_status:first_fixed": "2",
"product_status:known_affected": "711",
"product_status:known_not_affected": "99",
"product_status:recommended": "442",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2025-40271",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-40271.json",
"version": "50"
},
"vulnrichment": {
"containers": {
"adp": [
{
"affected": [
{
"defaultStatus": "unknown",
"product": "RUGGEDCOM RST2428P",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V4.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-02T13:00:17.378Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
}
],
"x_adpType": "supplier"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-40271",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T19:37:49.226666Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-16T19:37:56.227Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/proc/generic.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1d1596d68a6f11d28f677eedf6cf5b17dbfeb491",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "c81d0385500446efe48c305bbb83d47f2ae23a50",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "4cba73c4c89219beef7685a47374bf88b1022369",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "6f2482745e510ae1dacc9b090194b9c5f918d774",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "67272c11f379d9aa5e0f6b16286b9d89b3f76046",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "623bb26127fb581a741e880e1e1a47d79aecb6f8",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "03de7ff197a3d0e17d0d5c58fdac99a63cba8110",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "895b4c0c79b092d732544011c3cecaf7322c36a1",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/proc/generic.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.19"
},
{
"lessThan": "3.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.302",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.247",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.197",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.159",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.117",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.59",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.302",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.247",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.197",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.159",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.117",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.59",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.9",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "3.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u003edev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026proc_subdir_lock);\n [time window] | rb_erase(\u0026root-\u003esubdir_node, \u0026parent-\u003esubdir);\n | write_unlock(\u0026proc_subdir_lock);\n read_lock(\u0026proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)"
}
],
"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"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-30T06:02:14.392Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/1d1596d68a6f11d28f677eedf6cf5b17dbfeb491"
},
{
"url": "https://git.kernel.org/stable/c/c81d0385500446efe48c305bbb83d47f2ae23a50"
},
{
"url": "https://git.kernel.org/stable/c/4cba73c4c89219beef7685a47374bf88b1022369"
},
{
"url": "https://git.kernel.org/stable/c/6f2482745e510ae1dacc9b090194b9c5f918d774"
},
{
"url": "https://git.kernel.org/stable/c/67272c11f379d9aa5e0f6b16286b9d89b3f76046"
},
{
"url": "https://git.kernel.org/stable/c/623bb26127fb581a741e880e1e1a47d79aecb6f8"
},
{
"url": "https://git.kernel.org/stable/c/03de7ff197a3d0e17d0d5c58fdac99a63cba8110"
},
{
"url": "https://git.kernel.org/stable/c/895b4c0c79b092d732544011c3cecaf7322c36a1"
}
],
"title": "fs/proc: fix uaf in proc_readdir_de()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-40271",
"datePublished": "2025-12-06T21:50:53.266Z",
"dateReserved": "2025-04-16T07:20:57.183Z",
"dateUpdated": "2026-07-30T06:02:14.392Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
FKIE_CVE-2025-40271
Vulnerability from fkie_nvd - Published: 2025-12-06 22:15 - Updated: 2026-07-30 06:24| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/proc/generic.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1d1596d68a6f11d28f677eedf6cf5b17dbfeb491",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "c81d0385500446efe48c305bbb83d47f2ae23a50",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "4cba73c4c89219beef7685a47374bf88b1022369",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "6f2482745e510ae1dacc9b090194b9c5f918d774",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "67272c11f379d9aa5e0f6b16286b9d89b3f76046",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "623bb26127fb581a741e880e1e1a47d79aecb6f8",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "03de7ff197a3d0e17d0d5c58fdac99a63cba8110",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
},
{
"lessThan": "895b4c0c79b092d732544011c3cecaf7322c36a1",
"status": "affected",
"version": "710585d4922fd315f2cada8fbe550ae8ed23e994",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/proc/generic.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.19"
},
{
"lessThan": "3.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.302",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.247",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.197",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.159",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.117",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.59",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "RUGGEDCOM RST2428P",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V4.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u003edev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026proc_subdir_lock);\n [time window] | rb_erase(\u0026root-\u003esubdir_node, \u0026parent-\u003esubdir);\n | write_unlock(\u0026proc_subdir_lock);\n read_lock(\u0026proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)"
}
],
"id": "CVE-2025-40271",
"lastModified": "2026-07-30T06:24:24.733",
"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"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-40271",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T19:37:49.226666Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-12-06T22:15:54.737",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/03de7ff197a3d0e17d0d5c58fdac99a63cba8110"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1d1596d68a6f11d28f677eedf6cf5b17dbfeb491"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4cba73c4c89219beef7685a47374bf88b1022369"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/623bb26127fb581a741e880e1e1a47d79aecb6f8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/67272c11f379d9aa5e0f6b16286b9d89b3f76046"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6f2482745e510ae1dacc9b090194b9c5f918d774"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/895b4c0c79b092d732544011c3cecaf7322c36a1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c81d0385500446efe48c305bbb83d47f2ae23a50"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
GHSA-R37X-WMXH-7HVH
Vulnerability from github – Published: 2025-12-07 00:30 – Updated: 2026-07-30 06:32In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |
rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)
{
"affected": [],
"aliases": [
"CVE-2025-40271"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-06T22:15:54Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u003edev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026proc_subdir_lock);\n [time window] | rb_erase(\u0026root-\u003esubdir_node, \u0026parent-\u003esubdir);\n | write_unlock(\u0026proc_subdir_lock);\n read_lock(\u0026proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)",
"id": "GHSA-r37x-wmxh-7hvh",
"modified": "2026-07-30T06:32:19Z",
"published": "2025-12-07T00:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03de7ff197a3d0e17d0d5c58fdac99a63cba8110"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d1596d68a6f11d28f677eedf6cf5b17dbfeb491"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4cba73c4c89219beef7685a47374bf88b1022369"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/623bb26127fb581a741e880e1e1a47d79aecb6f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/67272c11f379d9aa5e0f6b16286b9d89b3f76046"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f2482745e510ae1dacc9b090194b9c5f918d774"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/895b4c0c79b092d732544011c3cecaf7322c36a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c81d0385500446efe48c305bbb83d47f2ae23a50"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
ICSA-26-188-05
Vulnerability from csaf_cisa - Published: 2026-06-02 00:00 - Updated: 2026-07-07 06:00OESA-2026-1306 (CVE-2023-53254)
Vulnerability from osv_openeuler – Published: 2026-02-06 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
cacheinfo: Fix shared_cpu_map to handle shared caches at different levels
The cacheinfo sets up the shared_cpu_map by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched shared_cpu_map when the shared cache does not have the same index between CPUs.
CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3
This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: Fix integer overflow in radeon_cs_parser_init
The type of size is unsigned, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later(CVE-2023-53309)
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-mem2mem: add lock to protect parameter num_rdy
Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.
kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&]
kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c(CVE-2023-53519)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex
Apparently the hex passphrase mechanism does not work on newer chips/firmware (e.g. BCM4387). It seems there was a simple way of passing it in binary all along, so use that and avoid the hexification.
OpenBSD has been doing it like this from the beginning, so this should work on all chips.
Also clear the structure before setting the PMK. This was leaking uninitialized stack contents to the device.(CVE-2023-53715)
In the Linux kernel, the following vulnerability has been resolved:
usb-storage: alauda: Fix uninit-value in alauda_check_media()
Syzbot got KMSAN to complain about access to an uninitialized value in the alauda subdriver of usb-storage:
BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0 drivers/usb/storage/alauda.c:1137 CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460
The problem is that alauda_check_media() doesn't verify that its USB transfer succeeded before trying to use the received data. What should happen if the transfer fails isn't entirely clear, but a reasonably conservative approach is to pretend that no media is present.
A similar problem exists in a usb_stor_dbg() call in alauda_get_media_status(). In this case, when an error occurs the call is redundant, because usb_stor_ctrl_transfer() already will print a debugging message.
Finally, unrelated to the uninitialized memory access, is the fact that alauda_check_media() performs DMA to a buffer on the stack. Fortunately usb-storage provides a general purpose DMA-able buffer for uses like this. We'll use it instead.(CVE-2023-53847)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()
The ucmd->log_sq_bb_count variable is controlled by the user so this shift can wrap. Fix it by using check_shl_overflow() in the same way that it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefined behavior in hns_roce_set_user_sq_size()").(CVE-2023-54168)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: fix pin_assignment_show
This patch fixes negative indexing of buf array in pin_assignment_show when get_current_pin_assignments returns 0 i.e. no compatible pin assignments are found.
BUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c ... Call trace: dump_backtrace+0x110/0x204 dump_stack_lvl+0x84/0xbc print_report+0x358/0x974 kasan_report+0x9c/0xfc __do_kernel_fault+0xd4/0x2d4 do_bad_area+0x48/0x168 do_tag_check_fault+0x24/0x38 do_mem_abort+0x6c/0x14c el1_abort+0x44/0x68 el1h_64_sync_handler+0x64/0xa4 el1h_64_sync+0x78/0x7c pin_assignment_show+0x26c/0x33c dev_attr_show+0x50/0xc0(CVE-2023-54186)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix memleak of md thread
In raid10_run(), if setup_conf() succeed and raid10_run() failed before setting 'mddev->thread', then in the error path 'conf->thread' is not freed.
Fix the problem by setting 'mddev->thread' right after setup_conf().(CVE-2023-54294)
In the Linux kernel, the following vulnerability has been resolved:
dm flakey: don't corrupt the zero page
When we need to zero some range on a block device, the function __blkdev_issue_zero_pages submits a write bio with the bio vector pointing to the zero page. If we use dm-flakey with corrupt bio writes option, it will corrupt the content of the zero page which results in crashes of various userspace programs. Glibc assumes that memory returned by mmap is zeroed and it uses it for calloc implementation; if the newly mapped memory is not zeroed, calloc will return non-zeroed memory.
Fix this bug by testing if the page is equal to ZERO_PAGE(0) and avoiding the corruption in this case.(CVE-2023-54317)
In the Linux kernel, the following vulnerability has been resolved:
clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns
What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to.
clone_private_mnt() checks the former, but not the latter.
There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above.(CVE-2025-38499)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: reject malicious packets in ipv6_gso_segment()
syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header.
This 16bit field has a limited range.
Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment()
WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: <TASK> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)
In the Linux kernel, the following vulnerability has been resolved:
vsock: Do not allow binding to VMADDR_PORT_ANY
It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction).
Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY.(CVE-2025-38618)
In the Linux kernel, the following vulnerability has been resolved:
pid: Add a judgment for ns null in pid_nr_ns
__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {
Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.
For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |
rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2602.1.0.0361.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2602.1.0.0361.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncacheinfo: Fix shared_cpu_map to handle shared caches at different levels\n\nThe cacheinfo sets up the shared_cpu_map by checking whether the caches\nwith the same index are shared between CPUs. However, this will trigger\nslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.\nAnother problem is the mismatched shared_cpu_map when the shared cache does\nnot have the same index between CPUs.\n\nCPU0\tI\tD\tL3\nindex\t0\t1\t2\tx\n\t^\t^\t^\t^\nindex\t0\t1\t2\t3\nCPU1\tI\tD\tL2\tL3\n\nThis patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: Fix integer overflow in radeon_cs_parser_init\n\nThe type of size is unsigned, if size is 0x40000000, there will be an\ninteger overflow, size will be zero after size *= sizeof(uint32_t),\nwill cause uninitialized memory to be referenced later(CVE-2023-53309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-mem2mem: add lock to protect parameter num_rdy\n\nGetting below error when using KCSAN to check the driver. Adding lock to\nprotect parameter num_rdy when getting the value with function:\nv4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.\n\nkworker/u16:3: [name:report\u0026amp;]BUG: KCSAN: data-race in v4l2_m2m_buf_queue\nkworker/u16:3: [name:report\u0026amp;]\n\nkworker/u16:3: [name:report\u0026amp;]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:\nkworker/u16:3:\u00a0 v4l2_m2m_buf_queue+0xd8/0x10c(CVE-2023-53519)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex\n\nApparently the hex passphrase mechanism does not work on newer\nchips/firmware (e.g. BCM4387). It seems there was a simple way of\npassing it in binary all along, so use that and avoid the hexification.\n\nOpenBSD has been doing it like this from the beginning, so this should\nwork on all chips.\n\nAlso clear the structure before setting the PMK. This was leaking\nuninitialized stack contents to the device.(CVE-2023-53715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb-storage: alauda: Fix uninit-value in alauda_check_media()\n\nSyzbot got KMSAN to complain about access to an uninitialized value in\nthe alauda subdriver of usb-storage:\n\nBUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0\ndrivers/usb/storage/alauda.c:1137\nCPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x191/0x1f0 lib/dump_stack.c:113\n kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108\n __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250\n alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460\n\nThe problem is that alauda_check_media() doesn\u0026apos;t verify that its USB\ntransfer succeeded before trying to use the received data. What\nshould happen if the transfer fails isn\u0026apos;t entirely clear, but a\nreasonably conservative approach is to pretend that no media is\npresent.\n\nA similar problem exists in a usb_stor_dbg() call in\nalauda_get_media_status(). In this case, when an error occurs the\ncall is redundant, because usb_stor_ctrl_transfer() already will print\na debugging message.\n\nFinally, unrelated to the uninitialized memory access, is the fact\nthat alauda_check_media() performs DMA to a buffer on the stack.\nFortunately usb-storage provides a general purpose DMA-able buffer for\nuses like this. We\u0026apos;ll use it instead.(CVE-2023-53847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Prevent shift wrapping in set_user_sq_size()\n\nThe ucmd-\u0026gt;log_sq_bb_count variable is controlled by the user so this\nshift can wrap. Fix it by using check_shl_overflow() in the same way\nthat it was done in commit 515f60004ed9 (\u0026quot;RDMA/hns: Prevent undefined\nbehavior in hns_roce_set_user_sq_size()\u0026quot;).(CVE-2023-54168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: altmodes/displayport: fix pin_assignment_show\n\nThis patch fixes negative indexing of buf array in pin_assignment_show\nwhen get_current_pin_assignments returns 0 i.e. no compatible pin\nassignments are found.\n\nBUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c\n...\nCall trace:\ndump_backtrace+0x110/0x204\ndump_stack_lvl+0x84/0xbc\nprint_report+0x358/0x974\nkasan_report+0x9c/0xfc\n__do_kernel_fault+0xd4/0x2d4\ndo_bad_area+0x48/0x168\ndo_tag_check_fault+0x24/0x38\ndo_mem_abort+0x6c/0x14c\nel1_abort+0x44/0x68\nel1h_64_sync_handler+0x64/0xa4\nel1h_64_sync+0x78/0x7c\npin_assignment_show+0x26c/0x33c\ndev_attr_show+0x50/0xc0(CVE-2023-54186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix memleak of md thread\n\nIn raid10_run(), if setup_conf() succeed and raid10_run() failed before\nsetting \u0026apos;mddev-\u0026gt;thread\u0026apos;, then in the error path \u0026apos;conf-\u0026gt;thread\u0026apos; is not\nfreed.\n\nFix the problem by setting \u0026apos;mddev-\u0026gt;thread\u0026apos; right after setup_conf().(CVE-2023-54294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm flakey: don\u0026apos;t corrupt the zero page\n\nWhen we need to zero some range on a block device, the function\n__blkdev_issue_zero_pages submits a write bio with the bio vector pointing\nto the zero page. If we use dm-flakey with corrupt bio writes option, it\nwill corrupt the content of the zero page which results in crashes of\nvarious userspace programs. Glibc assumes that memory returned by mmap is\nzeroed and it uses it for calloc implementation; if the newly mapped\nmemory is not zeroed, calloc will return non-zeroed memory.\n\nFix this bug by testing if the page is equal to ZERO_PAGE(0) and\navoiding the corruption in this case.(CVE-2023-54317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns\n\nWhat we want is to verify there is that clone won\u0026apos;t expose something\nhidden by a mount we wouldn\u0026apos;t be able to undo. \u0026quot;Wouldn\u0026apos;t be able to undo\u0026quot;\nmay be a result of MNT_LOCKED on a child, but it may also come from\nlacking admin rights in the userns of the namespace mount belongs to.\n\nclone_private_mnt() checks the former, but not the latter.\n\nThere\u0026apos;s a number of rather confusing CAP_SYS_ADMIN checks in various\nuserns during the mount, especially with the new mount API; they serve\ndifferent purposes and in case of clone_private_mnt() they usually,\nbut not always end up covering the missing check mentioned above.(CVE-2025-38499)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: reject malicious packets in ipv6_gso_segment()\n\nsyzbot was able to craft a packet with very long IPv6 extension headers\nleading to an overflow of skb-\u0026gt;transport_header.\n\nThis 16bit field has a limited range.\n\nAdd skb_reset_transport_header_careful() helper and use it\nfrom ipv6_gso_segment()\n\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nModules linked in:\nCPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\n RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\n RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110\n skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n __skb_gso_segment+0x342/0x510 net/core/gso.c:124\n skb_gso_segment include/net/gso.h:83 [inline]\n validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950\n validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000\n sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329\n __dev_xmit_skb net/core/dev.c:4102 [inline]\n __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Do not allow binding to VMADDR_PORT_ANY\n\nIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This can\ncause a use-after-free when a connection is made to the bound socket.\nThe socket returned by accept() also has port VMADDR_PORT_ANY but is not\non the list of unbound sockets. Binding it will result in an extra\nrefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep\nthe binding until socket destruction).\n\nModify the check in __vsock_bind_connectible() to also prevent binding\nto VMADDR_PORT_ANY.(CVE-2025-38618)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npid: Add a judgment for ns null in pid_nr_ns\n\n__task_pid_nr_ns\n ns = task_active_pid_ns(current);\n pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);\n if (pid \u0026amp;\u0026amp; ns-\u0026gt;level \u0026lt;= pid-\u0026gt;level) {\n\nSometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.\n\nFor example:\n\tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n\tMem abort info:\n\tESR = 0x0000000096000007\n\tEC = 0x25: DABT (current EL), IL = 32 bits\n\tSET = 0, FnV = 0\n\tEA = 0, S1PTW = 0\n\tFSC = 0x07: level 3 translation fault\n\tData abort info:\n\tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n\tCM = 0, WnR = 0, TnD = 0, TagAccess = 0\n\tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000\n\t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000\n\tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n\tpc : __task_pid_nr_ns+0x74/0xd0\n\tlr : __task_pid_nr_ns+0x24/0xd0\n\tsp : ffffffc08001bd10\n\tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001\n\tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31\n\tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0\n\tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000\n\tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc\n\tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800\n\tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001\n\tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449\n\tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc\n\tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0\n\tCall trace:\n\t__task_pid_nr_ns+0x74/0xd0\n\t...\n\t__handle_irq_event_percpu+0xd4/0x284\n\thandle_irq_event+0x48/0xb0\n\thandle_fasteoi_irq+0x160/0x2d8\n\tgeneric_handle_domain_irq+0x44/0x60\n\tgic_handle_irq+0x4c/0x114\n\tcall_on_irq_stack+0x3c/0x74\n\tdo_interrupt_handler+0x4c/0x84\n\tel1_interrupt+0x34/0x58\n\tel1h_64_irq_handler+0x18/0x24\n\tel1h_64_irq+0x68/0x6c\n\taccount_kernel_stack+0x60/0x144\n\texit_task_stack_account+0x1c/0x80\n\tdo_exit+0x7e4/0xaf8\n\t...\n\tget_signal+0x7bc/0x8d8\n\tdo_notify_resume+0x128/0x828\n\tel0_svc+0x6c/0x70\n\tel0t_64_sync_handler+0x68/0xbc\n\tel0t_64_sync+0x1a8/0x1ac\n\tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)\n\t---[ end trace 0000000000000000 ]---\n\tKernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u0026gt;dev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026amp;proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026amp;proc_subdir_lock);\n [time window] | rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n | write_unlock(\u0026amp;proc_subdir_lock);\n read_lock(\u0026amp;proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)(CVE-2025-40271)",
"id": "OESA-2026-1306",
"modified": "2026-08-06T11:10:20Z",
"published": "2026-02-06T11:10:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1306"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53519"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54186"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54294"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54317"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38499"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38572"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38618"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
}
],
"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-53254",
"CVE-2023-53309",
"CVE-2023-53519",
"CVE-2023-53715",
"CVE-2023-53847",
"CVE-2023-54168",
"CVE-2023-54186",
"CVE-2023-54294",
"CVE-2023-54317",
"CVE-2025-38499",
"CVE-2025-38572",
"CVE-2025-38618",
"CVE-2025-40178",
"CVE-2025-40271"
]
}
OESA-2026-1341 (CVE-2022-49190)
Vulnerability from osv_openeuler – Published: 2026-02-13 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource(). And it s required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)
In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below: (Thread 1) | (Thread 2) | _set_timer()rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...We hold pmlmepriv->lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv->lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obtainthe needed lock. What`s more, we change spin_lock_bh() inrtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,spin_lock_bh() will also cause deadlock() in timer handler.(CVE-2022-49309)
In the Linux kernel, the following vulnerability has been resolved:
drm/scheduler: fix fence ref counting
We leaked dependency fences when processes were beeing killed.
Additional to that grab a reference to the last scheduled fence.(CVE-2022-49829)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix random warning message when driver load
Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] slaballoc.part.108+0x4d4/0x748 [ 4.191419] slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0
pool_alloc_page(struct dma_pool pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... }
kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning.
GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely.(CVE-2022-50151)
In the Linux kernel, the following vulnerability has been resolved:
of: check previous kernel's ima-kexec-buffer against memory bounds
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below:
$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
<snip> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---
Fix this issue by checking returned PFN range of previous kernel's ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.(CVE-2022-50159)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Use different devices for resource allocation and DT lookup
Following by the below discussion, there's the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/(CVE-2022-50616)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: do not run mt76u_status_worker if the device is not running
Fix the following NULL pointer dereference avoiding to run mt76u_status_worker thread if the device is not running yet.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: mt76 mt76u_tx_status_data RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: mt76x02_send_tx_status+0x1d2/0xeb0 mt76x02_tx_status_data+0x8e/0xd0 mt76u_tx_status_data+0xe1/0x240 process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480 ret_from_fork+0x1f/0x30 Modules linked in: --[ end trace 8df5d20fc5040f65 ]-- RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554
Moreover move stat_work schedule out of the for loop.(CVE-2022-50735)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: allow exp not to be removed in nf_ct_find_expectation
Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches.
This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.(CVE-2023-52927)
In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 1373 Comm: modprobe Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:dmi_sysfs_entry_release ... Call Trace: <TASK> kobject_put dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs dmi_decode_table (drivers/firmware/dmi_scan.c:133) dmi_walk (drivers/firmware/dmi_scan.c:1115) dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs do_one_initcall (init/main.c:1296) ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x4000000 from 0xffffffff81000000 ---[ end Kernel panic - not syncing: Fatal exception ]---
It is because previous patch added kobject_put() to release the memory which will call dmi_sysfs_entry_release() and list_del().
However, list_add_tail(entry->list) is called after the error block, so the list_head is uninitialized and cannot be deleted.
Move error handling to after list_add_tail to fix this.(CVE-2023-53250)
In the Linux kernel, the following vulnerability has been resolved:
cacheinfo: Fix shared_cpu_map to handle shared caches at different levels
The cacheinfo sets up the shared_cpu_map by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched shared_cpu_map when the shared cache does not have the same index between CPUs.
CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3
This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()
A fix for:
BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses] Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013
When edev->components is zero, accessing edev->component[0] members is wrong.(CVE-2023-53521)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix resource leak in device_add()
When calling kobject_add() failed in device_add(), it will call cleanup_glue_dir() to free resource. But in kobject_add(), dev->kobj.parent has been set to NULL. This will cause resource leak.
The process is as follows: device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put()
The preceding problem may cause insmod mac80211_hwsim.ko to failed. sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim' Call Trace: <TASK> dump_stack_lvl+0x8e/0xd1 sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x224/0x280 kobject_add_internal+0x2aa/0x880 kobject_add+0x135/0x1a0 get_device_parent+0x3d7/0x590 device_add+0x2aa/0x1cb0 device_create_groups_vargs+0x1eb/0x260 device_create+0xdc/0x110 mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim] init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim] do_one_initcall+0x10f/0x630 do_init_module+0x19f/0x5e0 load_module+0x64b7/0x6eb0 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to register things with the same name in the same directory.(CVE-2023-53594)
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9317/1: kexec: Make smp stop calls asynchronous
If a panic is triggered by a hrtimer interrupt all online cpus will be notified and set offline. But as highlighted by commit 19dbdcb8039c ("smp: Warn on function calls from softirq context") this call should not be made synchronous with disabled interrupts:
softdog: Initiating panic Kernel panic - not syncing: Software Watchdog Timer expired WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond unwind_backtrace: show_stack dump_stack_lvl __warn warn_slowpath_fmt smp_call_function_many_cond smp_call_function crash_smp_send_stop.part.0 machine_crash_shutdown __crash_kexec panic softdog_fire __hrtimer_run_queues hrtimer_interrupt
Make the smp call for machine_crash_nonpanic_core() asynchronous.(CVE-2023-53712)
In the Linux kernel, the following vulnerability has been resolved:
usb: early: xhci-dbc: Fix a potential out-of-bound memory access
If xdbc_bulk_write() fails, the values in 'buf' can be anything. So the string is not guaranteed to be NULL terminated when xdbc_trace() is called.
Reserve an extra byte, which will be zeroed automatically because 'buf' is a static variable, in order to avoid troubles, should it happen.(CVE-2023-53840)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Prevent handling any completions after qp destroy
HW may generate completions that indicates QP is destroyed. Driver should not be scheduling any more completion handlers for this QP, after the QP is destroyed. Since CQs are active during the QP destroy, driver may still schedule completion handlers. This can cause a race where the destroy_cq and poll_cq running simultaneously.
Snippet of kernel panic while doing bnxt_re driver load unload in loop. This indicates a poll after the CQ is freed.
[77786.481636] Call Trace: [77786.481640] <TASK> [77786.481644] bnxt_re_poll_cq+0x14a/0x620 [bnxt_re] [77786.481658] ? kvm_clock_read+0x14/0x30 [77786.481693] __ib_process_cq+0x57/0x190 [ib_core] [77786.481728] ib_cq_poll_work+0x26/0x80 [ib_core] [77786.481761] process_one_work+0x1e5/0x3f0 [77786.481768] worker_thread+0x50/0x3a0 [77786.481785] ? __pfx_worker_thread+0x10/0x10 [77786.481790] kthread+0xe2/0x110 [77786.481794] ? __pfx_kthread+0x10/0x10 [77786.481797] ret_from_fork+0x2c/0x50
To avoid this, complete all completion handlers before returning the destroy QP. If free_cq is called soon after destroy_qp, IB stack will cancel the CQ work before invoking the destroy_cq verb and this will prevent any race mentioned.(CVE-2023-54048)
In the Linux kernel, the following vulnerability has been resolved:
bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log
It's trivial for user to trigger "verifier log line truncated" warning, as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at least two pieces of user-provided information that can be output through this buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.
Verifier log buffer should be properly sized for typical verifier state output. But it's sort-of expected that this buffer won't be long enough in some circumstances. So let's drop the check. In any case code will work correctly, at worst truncating a part of a single line output.(CVE-2023-54145)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential null-ptr-deref in device_add()
I got the following null-ptr-deref report while doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klist_put+0x2d/0xd0 Call Trace: <TASK> klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482]
This is how it happened:
w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device.
// error path
bus_remove_device()
// The dev->driver is not null, but driver is not bound.
__device_release_driver()
klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.
// normal path
bus_probe_device() // It's not called yet.
device_bind_driver()
If dev->driver is set, in the error path after calling bus_add_device() in device_add(), bus_remove_device() is called, then the device will be detached from driver. But device_bind_driver() is not called yet, so it causes null-ptr-deref while access the 'knode_driver'. To fix this, set dev->driver to null in the error path before calling bus_remove_device().(CVE-2023-54321)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free of signing key
Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race:
task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() UAF
Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING.(CVE-2024-53179)
In the Linux kernel, the following vulnerability has been resolved:
ice: fix memory leak in aRFS after reset
Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling
However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature:
[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ...(CVE-2025-21981)
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: fix pipe accounting mismatch
Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.
To remedy this, explicitly account for the pipe usage in watch_queue_set_size() to match the number set via account_pipe_buffers()
(It's unclear why watch_queue_set_size() does not update nr_accounted; it may be due to intentional overprovisioning in watch_queue_set_size()?)(CVE-2025-23138)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Prevent division by zero
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37766)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Prevent division by zero
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37770)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: prevent out-of-bounds stream writes by validating *pos
ksmbd_vfs_stream_write() did not validate whether the write offset (pos) was within the bounds of the existing stream data length (v_len). If pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write.
This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.(CVE-2025-37947)
In the Linux kernel, the following vulnerability has been resolved:
crypto: lzo - Fix compression buffer overrun
Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller.
Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo.(CVE-2025-38068)
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:
Bluetooth: hci_core: Fix use-after-free in vhci_flush()
syzbot reported use-after-free in vhci_flush() without repro. [0]
From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread.
Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data.
The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation.
We can use SRCU for such synchronisation.
Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev().
Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 ("Bluetooth: Remove unused hci-destruct cb"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat.
Note that other drivers seem to have the same problem, for exmaple, virtbt_remove().
[0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718
CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 </TASK>
Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---(CVE-2025-38250)
In the Linux kernel, the following vulnerability has been resolved:
comedi: Fix use of uninitialized data in insn_rw_emulate_bits()
For Comedi INSN_READ and INSN_WRITE instructions on "digital"
subdevices (subdevice types COMEDI_SUBD_DI, COMEDI_SUBD_DO, and
COMEDI_SUBD_DIO), it is common for the subdevice driver not to have
insn_read and insn_write handler functions, but to have an
insn_bits handler function for handling Comedi INSN_BITS
instructions. In that case, the subdevice's insn_read and/or
insn_write function handler pointers are set to point to the
insn_rw_emulate_bits() function by __comedi_device_postconfig().
For INSN_WRITE, insn_rw_emulate_bits() currently assumes that the
supplied data[0] value is a valid copy from user memory. It will at
least exist because do_insnlist_ioctl() and do_insn_ioctl() in
"comedi_fops.c" ensure at lease MIN_SAMPLES (16) elements are
allocated. However, if insn->n is 0 (which is allowable for
INSN_READ and INSN_WRITE instructions, then data[0] may contain
uninitialized data, and certainly contains invalid data, possibly from a
different instruction in the array of instructions handled by
do_insnlist_ioctl(). This will result in an incorrect value being
written to the digital output channel (or to the digital input/output
channel if configured as an output), and may be reflected in the
internal saved state of the channel.
Fix it by returning 0 early if insn->n is 0, before reaching the code
that accesses data[0]. Previously, the function always returned 1 on
success, but it is supposed to be the number of data samples actually
read or written up to insn->n, which is 0 in this case.(CVE-2025-38480)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Harden s32ton() against conversion to 0 bits
Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that.
Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.(CVE-2025-38556)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: reject malicious packets in ipv6_gso_segment()
syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header.
This 16bit field has a limited range.
Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment()
WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: <TASK> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)
In the Linux kernel, the following vulnerability has been resolved:
pptp: ensure minimal skb length in pptp_xmit()
Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on ppp_sync_txmung") fixed ppp_sync_txmunge()
We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot.
BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 _syssendmsg+0x893/0xd80 net/socket.c:2566 _sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)
In the Linux kernel, the following vulnerability has been resolved:
vsock: Do not allow binding to VMADDR_PORT_ANY
It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction).
Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY.(CVE-2025-38618)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Avoid stack buffer overflow from kernel cmdline
While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix for slab out of bounds on mount to ksmbd
With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below):
BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827
CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 cifs
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla4xxx: Prevent a potential error pointer dereference
The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error, but qla4xxx_ep_connect() returns error pointers. Propagating the error pointers will lead to an Oops in the caller, so change the error pointers to NULL.(CVE-2025-39676)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.(CVE-2025-39702)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.
This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.
irq_exit() __irq_exit_rcu() / in_hardirq() returns false after this / preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() / a bpf prog is hooked on this trace point / __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() / will send a IPI to itself / irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch:
static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +
neeraj: Apply Frederic's suggested fix for PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:
rcu: Protect ->defer_qs_iw_pending from data race
On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.
In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.
The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat:
BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special
read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0
The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.
This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Duplicate SPI Handling
The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses.
This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops.
According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol.
Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable.
Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI
Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.(CVE-2025-39797)
In the Linux kernel, the following vulnerability has been resolved:
atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().
syzbot reported the splat below. [0]
When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.
The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.
The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.
struct atmtcp_control { struct atmtcp_hdr hdr; / must be first / ... atm_kptr_t vcc; / both directions / ... } __ATM_API_ALIGN;
typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;
The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().
atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:
- .ndo_start_xmit() (vcc->send() == atm_send_aal0())
- vcc_sendmsg()
The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.
Let's add a new ->pre_send() hook to validate messages from sendmsg().
[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 _syssendmsg+0x505/0x830 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in:(CVE-2025-39828)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
syzbot reported the splat below without a repro.
In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that.
The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit.
bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release().
Two threads could see the same socket during the list iteration in bt_accept_dequeue():
CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF
Depending on the timing, the other thread could show up in the "Freed by task" part.
Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release().
[0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #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 Call Trace: <TASK> __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:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK>
Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---(CVE-2025-39860)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.
syzbot reported the splat below. [0]
The repro does the following:
- Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
- Attach the prog to a SOCKMAP
- Add a socket to the SOCKMAP
- Activate fault injection
- Send data less than cork_bytes
At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().
Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN.
If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc().
Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork.
The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.
[0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)
In the Linux kernel, the following vulnerability has been resolved:
cnic: Fix use-after-free bugs in cnic_delete_task
The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task().
A typical race condition is illustrated below:
CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | / the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed.
This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.(CVE-2025-39945)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: Defer ip_vs_ftp unregister during netns cleanup
On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.
Fix this by introducing a global exiting_module flag, set to true in
ip_vs_ftp_exit() before unregistering the pernet subsystem. In
__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
cleanup (when exiting_module is false) and defer it to
__ip_vs_cleanup_batch(), which unregisters all apps after all connections
are flushed. If called during module exit, unregister ip_vs_ftp
immediately.(CVE-2025-40018)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't leak disconnected dentries on umount
When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete x->tunnel as we delete x
The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.
We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.
Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.
A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.(CVE-2025-40215)
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |
rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free in tipc_mon_reinit_self().
syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0]
The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL.
tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work().
Let's hold RTNL in tipc_net_finalize_work().
[0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989
CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 _syssendmsg+0x508/0x820 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/ ---truncated---(CVE-2025-40280)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: use lock accessing port_state and rport state
nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.(CVE-2025-40342)
In the Linux kernel, the following vulnerability has been resolved:
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup
Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks.
Initialize the MAC header to prevent such crashes.
This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface.
Example trace:
Internal error: Oops: 000000009600004f [#1] SMP
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1
Hardware name: LS1028A RDB Board (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xfrm_input+0xde8/0x1318
lr : xfrm_input+0x61c/0x1318
sp : ffff800080003b20
Call trace:
xfrm_input+0xde8/0x1318
xfrm6_rcv+0x38/0x44
xfrm6_esp_rcv+0x48/0xa8
ip6_protocol_deliver_rcu+0x94/0x4b0
ip6_input_finish+0x44/0x70
ip6_input+0x44/0xc0
ipv6_rcv+0x6c/0x114
__netif_receive_skb_one_core+0x5c/0x8c
__netif_receive_skb+0x18/0x60
process_backlog+0x78/0x17c
__napi_poll+0x38/0x180
net_rx_action+0x168/0x2f0(CVE-2025-68192)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix potential use-after-free in have_mon_and_osd_map()
The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one
kfree(monc->monmap);
monc->monmap = monmap;
ceph_osdmap_destroy(osdc->osdmap);
osdc->osdmap = newmap;
under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in
client->monc.monmap && client->monc.monmap->epoch &&
client->osdc.osdmap && client->osdc.osdmap->epoch;
condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:
BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
...
Call Trace:
<TASK>
have_mon_and_osd_map+0x56/0x70
ceph_open_session+0x182/0x290
ceph_get_tree+0x333/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Allocated by task 13305:
ceph_osdmap_alloc+0x16/0x130
ceph_osdc_init+0x27a/0x4c0
ceph_create_client+0x153/0x190
create_fs_client+0x50/0x2a0
ceph_get_tree+0xff/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 9475:
kfree+0x212/0x290
handle_one_map+0x23c/0x3b0
ceph_osdc_handle_map+0x3c9/0x590
mon_dispatch+0x655/0x6f0
ceph_con_process_message+0xc3/0xe0
ceph_con_v1_try_read+0x614/0x760
ceph_con_workfn+0x2de/0x650
process_one_work+0x486/0x7c0
process_scheduled_works+0x73/0x90
worker_thread+0x1c8/0x2a0
kthread+0x2ec/0x300
ret_from_fork+0x24/0x40
ret_from_fork_asm+0x1a/0x30
Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth().
monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.(CVE-2025-68285)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()
rlen value is a user-controlled value, but dtv5100_i2c_msg() does not check the size of the rlen value. Therefore, if it is set to a value larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.
Therefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cm: Fix leaking the multicast GID table reference
If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN:
GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886
Destroy the ah_attr after canceling the work, it is safe to call this twice.(CVE-2025-71084)
In the Linux kernel, the following vulnerability has been resolved:
team: fix check for port enabled in team_queue_override_port_prio_changed()
There has been a syzkaller bug reported recently with the following trace:
list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:59! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #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:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59 Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0 Call Trace: <TASK> __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] _syssendmsg+0xa98/0xc70 net/socket.c:2630 _sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
The problem is in this flow: 1) Port is enabled, queue_id != 0, in qom_list 2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list) 3) Port is disabled, queue_id != 0, not in any list 4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed already
To fix this, change the check in team_queue_override_port_prio_changed() so it returns early if port is not enabled.(CVE-2025-71091)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf
A zero length gss_token results in pages == 0 and in_token->pages[0] is NULL. The code unconditionally evaluates page_address(in_token->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.(CVE-2025-71120)
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec
Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs.
The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.
Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL
The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated(CVE-2026-22998)
In the Linux kernel, the following vulnerability has been resolved:
pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()
In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak.
Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"perf-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-301.0.0.204.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"perf-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-301.0.0.204.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-301.0.0.204.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:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource(). And it s required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)\n\nIn the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below: (Thread 1) | (Thread 2) | _set_timer()rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...We hold pmlmepriv-\u0026gt;lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv-\u0026gt;lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obtainthe needed lock. What`s more, we change spin_lock_bh() inrtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,spin_lock_bh() will also cause deadlock() in timer handler.(CVE-2022-49309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/scheduler: fix fence ref counting\n\nWe leaked dependency fences when processes were beeing killed.\n\nAdditional to that grab a reference to the last scheduled fence.(CVE-2022-49829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix random warning message when driver load\n\nWarning log:\n[ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code!\n[ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20\n[ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT)\n[ 4.163155] Call trace:\n[ 4.165600] dump_backtrace+0x0/0x1b0\n[ 4.169286] show_stack+0x18/0x68\n[ 4.172611] dump_stack_lvl+0x68/0x84\n[ 4.176286] dump_stack+0x18/0x34\n[ 4.179613] kmalloc_fix_flags+0x60/0x88\n[ 4.183550] new_slab+0x334/0x370\n[ 4.186878] ___slab_alloc.part.108+0x4d4/0x748\n[ 4.191419] __slab_alloc.isra.109+0x30/0x78\n[ 4.195702] kmem_cache_alloc+0x40c/0x420\n[ 4.199725] dma_pool_alloc+0xac/0x1f8\n[ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0\n\npool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)\n{\n\t...\n\tpage = kmalloc(sizeof(*page), mem_flags);\n\tpage-\u0026gt;vaddr = dma_alloc_coherent(pool-\u0026gt;dev, pool-\u0026gt;allocation,\n\t\t\t\t\t \u0026amp;page-\u0026gt;dma, mem_flags);\n\t...\n}\n\nkmalloc was called with mem_flags, which is passed down in\ncdns3_allocate_trb_pool() and have GFP_DMA32 flags.\nkmall_fix_flags() report warning.\n\nGFP_DMA32 is not useful at all. dma_alloc_coherent() will handle\nDMA memory region correctly by pool-\u0026gt;dev. GFP_DMA32 can be removed\nsafely.(CVE-2022-50151)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nof: check previous kernel\u0026apos;s ima-kexec-buffer against memory bounds\n\nPresently ima_get_kexec_buffer() doesn\u0026apos;t check if the previous kernel\u0026apos;s\nima-kexec-buffer lies outside the addressable memory range. This can result\nin a kernel panic if the new kernel is booted with \u0026apos;mem=X\u0026apos; arg and the\nima-kexec-buffer was allocated beyond that range by the previous kernel.\nThe panic is usually of the form below:\n\n$ sudo kexec --initrd initrd vmlinux --append=\u0026apos;mem=16G\u0026apos;\n\n\u0026lt;snip\u0026gt;\n BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000\n Faulting instruction address: 0xc000000000837974\n Oops: Kernel access of bad area, sig: 11 [#1]\n\u0026lt;snip\u0026gt;\n NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0\n LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160\n Call Trace:\n [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160\n [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108\n [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120\n [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0\n [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec\n [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0\n [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64\n Instruction dump:\n f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330\n 7c0802a6 fb610198 7c9b2378 f80101d0 \u0026lt;a1240000\u0026gt; 2c090001 40820614 e9240010\n ---[ end trace 0000000000000000 ]---\n\nFix this issue by checking returned PFN range of previous kernel\u0026apos;s\nima-kexec-buffer with page_is_ram() to ensure correct memory bounds.(CVE-2022-50159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Use different devices for resource allocation and DT lookup\n\nFollowing by the below discussion, there\u0026apos;s the potential UAF issue\nbetween regulator and mfd.\nhttps://lore.kernel.org/all/(CVE-2022-50616)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: do not run mt76u_status_worker if the device is not running\n\nFix the following NULL pointer dereference avoiding to run\nmt76u_status_worker thread if the device is not running yet.\n\nKASAN: null-ptr-deref in range\n[0x0000000000000000-0x0000000000000007]\nCPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware\nname: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nWorkqueue: mt76 mt76u_tx_status_data\nRIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0\nCode: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00\n48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 \u0026lt;0f\u0026gt;\nb6\n04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7\nRSP: 0018:ffffc900005af988 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a\nRBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c\nR10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8\nR13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28\nFS: 0000000000000000(0000) GS:ffff88811aa00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n mt76x02_send_tx_status+0x1d2/0xeb0\n mt76x02_tx_status_data+0x8e/0xd0\n mt76u_tx_status_data+0xe1/0x240\n process_one_work+0x92b/0x1460\n worker_thread+0x95/0xe00\n kthread+0x3a1/0x480\n ret_from_fork+0x1f/0x30\nModules linked in:\n--[ end trace 8df5d20fc5040f65 ]--\nRIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0\nCode: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00\n48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 \u0026lt;0f\u0026gt;\nb6\n04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7\nRSP: 0018:ffffc900005af988 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a\nRBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c\nR10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8\nR13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28\nFS: 0000000000000000(0000) GS:ffff88811aa00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0\nPKRU: 55555554\n\nMoreover move stat_work schedule out of the for loop.(CVE-2022-50735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: allow exp not to be removed in nf_ct_find_expectation\n\nCurrently nf_conntrack_in() calling nf_ct_find_expectation() will\nremove the exp from the hash table. However, in some scenario, we\nexpect the exp not to be removed when the created ct will not be\nconfirmed, like in OVS and TC conntrack in the following patches.\n\nThis patch allows exp not to be removed by setting IPS_CONFIRMED\nin the status of the tmpl.(CVE-2023-52927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle\n\nKASAN reported a null-ptr-deref error:\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 1373 Comm: modprobe\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:dmi_sysfs_entry_release\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kobject_put\n dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs\n dmi_decode_table (drivers/firmware/dmi_scan.c:133)\n dmi_walk (drivers/firmware/dmi_scan.c:1115)\n dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs\n do_one_initcall (init/main.c:1296)\n ...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x4000000 from 0xffffffff81000000\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nIt is because previous patch added kobject_put() to release the memory\nwhich will call dmi_sysfs_entry_release() and list_del().\n\nHowever, list_add_tail(entry-\u0026gt;list) is called after the error block,\nso the list_head is uninitialized and cannot be deleted.\n\nMove error handling to after list_add_tail to fix this.(CVE-2023-53250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncacheinfo: Fix shared_cpu_map to handle shared caches at different levels\n\nThe cacheinfo sets up the shared_cpu_map by checking whether the caches\nwith the same index are shared between CPUs. However, this will trigger\nslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.\nAnother problem is the mismatched shared_cpu_map when the shared cache does\nnot have the same index between CPUs.\n\nCPU0\tI\tD\tL3\nindex\t0\t1\t2\tx\n\t^\t^\t^\t^\nindex\t0\t1\t2\t3\nCPU1\tI\tD\tL2\tL3\n\nThis patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix slab-out-of-bounds in ses_intf_remove()\n\nA fix for:\n\nBUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]\nRead of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013\n\nWhen edev-\u0026gt;components is zero, accessing edev-\u0026gt;component[0] members is\nwrong.(CVE-2023-53521)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix resource leak in device_add()\n\nWhen calling kobject_add() failed in device_add(), it will call\ncleanup_glue_dir() to free resource. But in kobject_add(),\ndev-\u0026gt;kobj.parent has been set to NULL. This will cause resource leak.\n\nThe process is as follows:\ndevice_add()\n\tget_device_parent()\n\t\tclass_dir_create_and_add()\n\t\t\tkobject_add()\t\t//kobject_get()\n\t...\n\tdev-\u0026gt;kobj.parent = kobj;\n\t...\n\tkobject_add()\t\t//failed, but set dev-\u0026gt;kobj.parent = NULL\n\t...\n\tglue_dir = get_glue_dir(dev)\t//glue_dir = NULL, and goto\n\t\t\t\t\t//\u0026quot;Error\u0026quot; label\n\t...\n\tcleanup_glue_dir()\t//becaues glue_dir is NULL, not call\n\t\t\t\t//kobject_put()\n\nThe preceding problem may cause insmod mac80211_hwsim.ko to failed.\nsysfs: cannot create duplicate filename \u0026apos;/devices/virtual/mac80211_hwsim\u0026apos;\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x8e/0xd1\nsysfs_warn_dup.cold+0x1c/0x29\nsysfs_create_dir_ns+0x224/0x280\nkobject_add_internal+0x2aa/0x880\nkobject_add+0x135/0x1a0\nget_device_parent+0x3d7/0x590\ndevice_add+0x2aa/0x1cb0\ndevice_create_groups_vargs+0x1eb/0x260\ndevice_create+0xdc/0x110\nmac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]\ninit_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]\ndo_one_initcall+0x10f/0x630\ndo_init_module+0x19f/0x5e0\nload_module+0x64b7/0x6eb0\n__do_sys_finit_module+0x140/0x200\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\n\u0026lt;/TASK\u0026gt;\nkobject_add_internal failed for mac80211_hwsim with -EEXIST, don\u0026apos;t try to\nregister things with the same name in the same directory.(CVE-2023-53594)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: 9317/1: kexec: Make smp stop calls asynchronous\n\nIf a panic is triggered by a hrtimer interrupt all online cpus will be\nnotified and set offline. But as highlighted by commit 19dbdcb8039c\n(\u0026quot;smp: Warn on function calls from softirq context\u0026quot;) this call should\nnot be made synchronous with disabled interrupts:\n\n softdog: Initiating panic\n Kernel panic - not syncing: Software Watchdog Timer expired\n WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond\n unwind_backtrace:\n show_stack\n dump_stack_lvl\n __warn\n warn_slowpath_fmt\n smp_call_function_many_cond\n smp_call_function\n crash_smp_send_stop.part.0\n machine_crash_shutdown\n __crash_kexec\n panic\n softdog_fire\n __hrtimer_run_queues\n hrtimer_interrupt\n\nMake the smp call for machine_crash_nonpanic_core() asynchronous.(CVE-2023-53712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: early: xhci-dbc: Fix a potential out-of-bound memory access\n\nIf xdbc_bulk_write() fails, the values in \u0026apos;buf\u0026apos; can be anything. So the\nstring is not guaranteed to be NULL terminated when xdbc_trace() is called.\n\nReserve an extra byte, which will be zeroed automatically because \u0026apos;buf\u0026apos; is\na static variable, in order to avoid troubles, should it happen.(CVE-2023-53840)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Prevent handling any completions after qp destroy\n\nHW may generate completions that indicates QP is destroyed.\nDriver should not be scheduling any more completion handlers\nfor this QP, after the QP is destroyed. Since CQs are active\nduring the QP destroy, driver may still schedule completion\nhandlers. This can cause a race where the destroy_cq and poll_cq\nrunning simultaneously.\n\nSnippet of kernel panic while doing bnxt_re driver load unload in loop.\nThis indicates a poll after the CQ is freed.\u00a0\n\n[77786.481636] Call Trace:\n[77786.481640] \u00a0\u0026lt;TASK\u0026gt;\n[77786.481644] \u00a0bnxt_re_poll_cq+0x14a/0x620 [bnxt_re]\n[77786.481658] \u00a0? kvm_clock_read+0x14/0x30\n[77786.481693] \u00a0__ib_process_cq+0x57/0x190 [ib_core]\n[77786.481728] \u00a0ib_cq_poll_work+0x26/0x80 [ib_core]\n[77786.481761] \u00a0process_one_work+0x1e5/0x3f0\n[77786.481768] \u00a0worker_thread+0x50/0x3a0\n[77786.481785] \u00a0? __pfx_worker_thread+0x10/0x10\n[77786.481790] \u00a0kthread+0xe2/0x110\n[77786.481794] \u00a0? __pfx_kthread+0x10/0x10\n[77786.481797] \u00a0ret_from_fork+0x2c/0x50\n\nTo avoid this, complete all completion handlers before returning the\ndestroy QP. If free_cq is called soon after destroy_qp, IB stack\nwill cancel the CQ work before invoking the destroy_cq verb and\nthis will prevent any race mentioned.(CVE-2023-54048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log\n\nIt\u0026apos;s trivial for user to trigger \u0026quot;verifier log line truncated\u0026quot; warning,\nas verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at\nleast two pieces of user-provided information that can be output through\nthis buffer, and both can be arbitrarily sized by user:\n - BTF names;\n - BTF.ext source code lines strings.\n\nVerifier log buffer should be properly sized for typical verifier state\noutput. But it\u0026apos;s sort-of expected that this buffer won\u0026apos;t be long enough\nin some circumstances. So let\u0026apos;s drop the check. In any case code will\nwork correctly, at worst truncating a part of a single line output.(CVE-2023-54145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential null-ptr-deref in device_add()\n\nI got the following null-ptr-deref report while doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nCPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x196/0x210\n bus_remove_device+0x1bd/0x240\n device_add+0xd3d/0x1100\n w1_add_master_device+0x476/0x490 [wire]\n ds2482_probe+0x303/0x3e0 [ds2482]\n\nThis is how it happened:\n\nw1_alloc_dev()\n // The dev-\u0026gt;driver is set to w1_master_driver.\n memcpy(\u0026amp;dev-\u0026gt;dev, device, sizeof(struct device));\n device_add()\n bus_add_device()\n dpm_sysfs_add() // It fails, calls bus_remove_device.\n\n // error path\n bus_remove_device()\n // The dev-\u0026gt;driver is not null, but driver is not bound.\n __device_release_driver()\n klist_remove(\u0026amp;dev-\u0026gt;p-\u0026gt;knode_driver) \u0026lt;-- It causes null-ptr-deref.\n\n // normal path\n bus_probe_device() // It\u0026apos;s not called yet.\n device_bind_driver()\n\nIf dev-\u0026gt;driver is set, in the error path after calling bus_add_device()\nin device_add(), bus_remove_device() is called, then the device will be\ndetached from driver. But device_bind_driver() is not called yet, so it\ncauses null-ptr-deref while access the \u0026apos;knode_driver\u0026apos;. To fix this, set\ndev-\u0026gt;driver to null in the error path before calling bus_remove_device().(CVE-2023-54321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free of signing key\n\nCustomers have reported use-after-free in @ses-\u0026gt;auth_key.response with\nSMB2.1 + sign mounts which occurs due to following race:\n\ntask A task B\ncifs_mount()\n dfs_mount_share()\n get_session()\n cifs_mount_get_session() cifs_send_recv()\n cifs_get_smb_ses() compound_send_recv()\n cifs_setup_session() smb2_setup_request()\n kfree_sensitive() smb2_calc_signature()\n crypto_shash_setkey() *UAF*\n\nFix this by ensuring that we have a valid @ses-\u0026gt;auth_key.response by\nchecking whether @ses-\u0026gt;ses_status is SES_GOOD or SES_EXITING with\n@ses-\u0026gt;ses_lock held. After commit 24a9799aa8ef (\u0026quot;smb: client: fix UAF\nin smb2_reconnect_server()\u0026quot;), we made sure to call -\u0026gt;logoff() only\nwhen @ses was known to be good (e.g. valid -\u0026gt;auth_key.response), so\nit\u0026apos;s safe to access signing key when @ses-\u0026gt;ses_status == SES_EXITING.(CVE-2024-53179)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix memory leak in aRFS after reset\n\nFix aRFS (accelerated Receive Flow Steering) structures memory leak by\nadding a checker to verify if aRFS memory is already allocated while\nconfiguring VSI. aRFS objects are allocated in two cases:\n- as part of VSI initialization (at probe), and\n- as part of reset handling\n\nHowever, VSI reconfiguration executed during reset involves memory\nallocation one more time, without prior releasing already allocated\nresources. This led to the memory leak with the following signature:\n\n[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak\nunreferenced object 0xff3c1ca7252e6000 (size 8192):\n comm \u0026quot;kworker/0:0\u0026quot;, pid 8, jiffies 4296833052\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 0):\n [\u0026lt;ffffffff991ec485\u0026gt;] __kmalloc_cache_noprof+0x275/0x340\n [\u0026lt;ffffffffc0a6e06a\u0026gt;] ice_init_arfs+0x3a/0xe0 [ice]\n [\u0026lt;ffffffffc09f1027\u0026gt;] ice_vsi_cfg_def+0x607/0x850 [ice]\n [\u0026lt;ffffffffc09f244b\u0026gt;] ice_vsi_setup+0x5b/0x130 [ice]\n [\u0026lt;ffffffffc09c2131\u0026gt;] ice_init+0x1c1/0x460 [ice]\n [\u0026lt;ffffffffc09c64af\u0026gt;] ice_probe+0x2af/0x520 [ice]\n [\u0026lt;ffffffff994fbcd3\u0026gt;] local_pci_probe+0x43/0xa0\n [\u0026lt;ffffffff98f07103\u0026gt;] work_for_cpu_fn+0x13/0x20\n [\u0026lt;ffffffff98f0b6d9\u0026gt;] process_one_work+0x179/0x390\n [\u0026lt;ffffffff98f0c1e9\u0026gt;] worker_thread+0x239/0x340\n [\u0026lt;ffffffff98f14abc\u0026gt;] kthread+0xcc/0x100\n [\u0026lt;ffffffff98e45a6d\u0026gt;] ret_from_fork+0x2d/0x50\n [\u0026lt;ffffffff98e083ba\u0026gt;] ret_from_fork_asm+0x1a/0x30\n ...(CVE-2025-21981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: fix pipe accounting mismatch\n\nCurrently, watch_queue_set_size() modifies the pipe buffers charged to\nuser-\u0026gt;pipe_bufs without updating the pipe-\u0026gt;nr_accounted on the pipe\nitself, due to the if (!pipe_has_watch_queue()) test in\npipe_resize_ring(). This means that when the pipe is ultimately freed,\nwe decrement user-\u0026gt;pipe_bufs by something other than what than we had\ncharged to it, potentially leading to an underflow. This in turn can\ncause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.\n\nTo remedy this, explicitly account for the pipe usage in\nwatch_queue_set_size() to match the number set via account_pipe_buffers()\n\n(It\u0026apos;s unclear why watch_queue_set_size() does not update nr_accounted;\nit may be due to intentional overprovisioning in watch_queue_set_size()?)(CVE-2025-23138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37766)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37770)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent out-of-bounds stream writes by validating *pos\n\nksmbd_vfs_stream_write() did not validate whether the write offset\n(*pos) was within the bounds of the existing stream data length (v_len).\nIf *pos was greater than or equal to v_len, this could lead to an\nout-of-bounds memory write.\n\nThis patch adds a check to ensure *pos is less than v_len before\nproceeding. If the condition fails, -EINVAL is returned.(CVE-2025-37947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: lzo - Fix compression buffer overrun\n\nUnlike the decompression code, the compression code in LZO never\nchecked for output overruns. It instead assumes that the caller\nalways provides enough buffer space, disregarding the buffer length\nprovided by the caller.\n\nAdd a safe compression interface that checks for the end of buffer\nbefore each write. Use the safe interface in crypto/lzo.(CVE-2025-38068)\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\nBluetooth: hci_core: Fix use-after-free in vhci_flush()\n\nsyzbot reported use-after-free in vhci_flush() without repro. [0]\n\nFrom the splat, a thread close()d a vhci file descriptor while\nits device was being used by iotcl() on another thread.\n\nOnce the last fd refcnt is released, vhci_release() calls\nhci_unregister_dev(), hci_free_dev(), and kfree() for struct\nvhci_data, which is set to hci_dev-\u0026gt;dev-\u0026gt;driver_data.\n\nThe problem is that there is no synchronisation after unlinking\nhdev from hci_dev_list in hci_unregister_dev(). There might be\nanother thread still accessing the hdev which was fetched before\nthe unlink operation.\n\nWe can use SRCU for such synchronisation.\n\nLet\u0026apos;s run hci_dev_reset() under SRCU and wait for its completion\nin hci_unregister_dev().\n\nAnother option would be to restore hci_dev-\u0026gt;destruct(), which was\nremoved in commit 587ae086f6e4 (\u0026quot;Bluetooth: Remove unused\nhci-destruct cb\u0026quot;). However, this would not be a good solution, as\nwe should not run hci_unregister_dev() while there are in-flight\nioctl() requests, which could lead to another data-race KCSAN splat.\n\nNote that other drivers seem to have the same problem, for exmaple,\nvirtbt_remove().\n\n[0]:\nBUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]\nBUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937\nRead of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718\n\nCPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xd2/0x2b0 mm/kasan/report.c:521\n kasan_report+0x118/0x150 mm/kasan/report.c:634\n skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]\n skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937\n skb_queue_purge include/linux/skbuff.h:3368 [inline]\n vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69\n hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]\n hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592\n sock_do_ioctl+0xd9/0x300 net/socket.c:1190\n sock_ioctl+0x576/0x790 net/socket.c:1311\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fcf5b98e929\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929\nRDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009\nRBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 6535:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635\n misc_open+0x2bc/0x330 drivers/char/misc.c:161\n chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414\n do_dentry_open+0xdf0/0x1970 fs/open.c:964\n vfs_open+0x3b/0x340 fs/open.c:1094\n do_open fs/namei.c:3887 [inline]\n path_openat+0x2ee5/0x3830 fs/name\n---truncated---(CVE-2025-38250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Fix use of uninitialized data in insn_rw_emulate_bits()\n\nFor Comedi `INSN_READ` and `INSN_WRITE` instructions on \u0026quot;digital\u0026quot;\nsubdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and\n`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have\n`insn_read` and `insn_write` handler functions, but to have an\n`insn_bits` handler function for handling Comedi `INSN_BITS`\ninstructions. In that case, the subdevice\u0026apos;s `insn_read` and/or\n`insn_write` function handler pointers are set to point to the\n`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.\n\nFor `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the\nsupplied `data[0]` value is a valid copy from user memory. It will at\nleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in\n\u0026quot;comedi_fops.c\u0026quot; ensure at lease `MIN_SAMPLES` (16) elements are\nallocated. However, if `insn-\u0026gt;n` is 0 (which is allowable for\n`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain\nuninitialized data, and certainly contains invalid data, possibly from a\ndifferent instruction in the array of instructions handled by\n`do_insnlist_ioctl()`. This will result in an incorrect value being\nwritten to the digital output channel (or to the digital input/output\nchannel if configured as an output), and may be reflected in the\ninternal saved state of the channel.\n\nFix it by returning 0 early if `insn-\u0026gt;n` is 0, before reaching the code\nthat accesses `data[0]`. Previously, the function always returned 1 on\nsuccess, but it is supposed to be the number of data samples actually\nread or written up to `insn-\u0026gt;n`, which is 0 in this case.(CVE-2025-38480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Harden s32ton() against conversion to 0 bits\n\nTesting by the syzbot fuzzer showed that the HID core gets a\nshift-out-of-bounds exception when it tries to convert a 32-bit\nquantity to a 0-bit quantity. Ideally this should never occur, but\nthere are buggy devices and some might have a report field with size\nset to zero; we shouldn\u0026apos;t reject the report or the device just because\nof that.\n\nInstead, harden the s32ton() routine so that it returns a reasonable\nresult instead of crashing when it is called with the number of bits\nset to 0 -- the same as what snto32() does.(CVE-2025-38556)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: reject malicious packets in ipv6_gso_segment()\n\nsyzbot was able to craft a packet with very long IPv6 extension headers\nleading to an overflow of skb-\u0026gt;transport_header.\n\nThis 16bit field has a limited range.\n\nAdd skb_reset_transport_header_careful() helper and use it\nfrom ipv6_gso_segment()\n\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nModules linked in:\nCPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\n RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\n RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110\n skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n __skb_gso_segment+0x342/0x510 net/core/gso.c:124\n skb_gso_segment include/net/gso.h:83 [inline]\n validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950\n validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000\n sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329\n __dev_xmit_skb net/core/dev.c:4102 [inline]\n __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npptp: ensure minimal skb length in pptp_xmit()\n\nCommit aabc6596ffb3 (\u0026quot;net: ppp: Add bound checking for skb data\non ppp_sync_txmung\u0026quot;) fixed ppp_sync_txmunge()\n\nWe need a similar fix in pptp_xmit(), otherwise we might\nread uninit data as reported by syzbot.\n\nBUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]\n ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314\n pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:727\n ____sys_sendmsg+0x893/0xd80 net/socket.c:2566\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620\n __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Do not allow binding to VMADDR_PORT_ANY\n\nIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This can\ncause a use-after-free when a connection is made to the bound socket.\nThe socket returned by accept() also has port VMADDR_PORT_ANY but is not\non the list of unbound sockets. Binding it will result in an extra\nrefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep\nthe binding until socket destruction).\n\nModify the check in __vsock_bind_connectible() to also prevent binding\nto VMADDR_PORT_ANY.(CVE-2025-38618)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Avoid stack buffer overflow from kernel cmdline\n\nWhile the kernel command line is considered trusted in most environments,\navoid writing 1 byte past the end of \u0026quot;acpiid\u0026quot; if the \u0026quot;str\u0026quot; argument is\nmaximum length.(CVE-2025-38676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix for slab out of bounds on mount to ksmbd\n\nWith KASAN enabled, it is possible to get a slab out of bounds\nduring mount to ksmbd due to missing check in parse_server_interfaces()\n(see below):\n\n BUG: KASAN: slab-out-of-bounds in\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n Read of size 4 at addr ffff8881433dba98 by task mount/9827\n\n CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G\n OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary)\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,\n BIOS 2.13.1 06/14/2019\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x9f/0xf0\n print_report+0xd1/0x670\n __virt_addr_valid+0x22c/0x430\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? kasan_complete_mode_report_info+0x2a/0x1f0\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n kasan_report+0xd6/0x110\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n __asan_report_load_n_noabort+0x13/0x20\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]\n ? trace_hardirqs_on+0x51/0x60\n SMB3_request_interfaces+0x1ad/0x3f0 [cifs]\n ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]\n ? SMB2_tcon+0x23c/0x15d0 [cifs]\n smb3_qfs_tcon+0x173/0x2b0 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n cifs_mount_get_tcon+0x369/0xb90 [cifs]\n ? dfs_cache_find+0xe7/0x150 [cifs]\n dfs_mount_share+0x985/0x2970 [cifs]\n ? check_path.constprop.0+0x28/0x50\n ? save_trace+0x54/0x370\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? __lock_acquire+0xb82/0x2ba0\n ? __kasan_check_write+0x18/0x20\n cifs_mount+0xbc/0x9e0 [cifs]\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]\n cifs_smb3_do_mount+0x263/0x1990 [cifs](CVE-2025-38728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla4xxx: Prevent a potential error pointer dereference\n\nThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,\nbut qla4xxx_ep_connect() returns error pointers. Propagating the error\npointers will lead to an Oops in the caller, so change the error pointers\nto NULL.(CVE-2025-39676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sr: Fix MAC comparison to be constant-time\n\nTo prevent timing attacks, MACs need to be compared in constant time.\nUse the appropriate helper function for this.(CVE-2025-39702)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix rcu_read_unlock() deadloop due to IRQ work\n\nDuring rcu_read_unlock_special(), if this happens during irq_exit(), we\ncan lockup if an IPI is issued. This is because the IPI itself triggers\nthe irq_exit() path causing a recursive lock up.\n\nThis is precisely what Xiongfeng found when invoking a BPF program on\nthe trace_tick_stop() tracepoint As shown in the trace below. Fix by\nmanaging the irq_work state correctly.\n\nirq_exit()\n __irq_exit_rcu()\n /* in_hardirq() returns false after this */\n preempt_count_sub(HARDIRQ_OFFSET)\n tick_irq_exit()\n tick_nohz_irq_exit()\n\t tick_nohz_stop_sched_tick()\n\t trace_tick_stop() /* a bpf prog is hooked on this trace point */\n\t\t __bpf_trace_tick_stop()\n\t\t bpf_trace_run2()\n\t\t\t rcu_read_unlock_special()\n /* will send a IPI to itself */\n\t\t\t irq_work_queue_on(\u0026amp;rdp-\u0026gt;defer_qs_iw, rdp-\u0026gt;cpu);\n\nA simple reproducer can also be obtained by doing the following in\ntick_irq_exit(). It will hang on boot without the patch:\n\n static inline void tick_irq_exit(void)\n {\n +\trcu_read_lock();\n +\tWRITE_ONCE(current-\u0026gt;rcu_read_unlock_special.b.need_qs, true);\n +\trcu_read_unlock();\n +\n\n[neeraj: Apply Frederic\u0026apos;s suggested fix for PREEMPT_RT](CVE-2025-39744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect -\u0026gt;defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won\u0026apos;t happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure\u0026apos;s -\u0026gt;defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special(). This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last enabled at (200272): [\u0026lt;ffffffffb0f56121\u0026gt;] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [\u0026lt;ffffffffb25c7859\u0026gt;] __schedule+0x129/0xd70\nsoftirqs last enabled at (0): [\u0026lt;ffffffffb0ee093f\u0026gt;] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special(). In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe -\u0026gt;defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the -\u0026gt;defer_qs_iw_pending\nfield. This suffices because this handler is not a fast path.(CVE-2025-39749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Duplicate SPI Handling\n\nThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI\nNetlink message, which triggers the kernel function xfrm_alloc_spi().\nThis function is expected to ensure uniqueness of the Security Parameter\nIndex (SPI) for inbound Security Associations (SAs). However, it can\nreturn success even when the requested SPI is already in use, leading\nto duplicate SPIs assigned to multiple inbound SAs, differentiated\nonly by their destination addresses.\n\nThis behavior causes inconsistencies during SPI lookups for inbound packets.\nSince the lookup may return an arbitrary SA among those with the same SPI,\npacket processing can fail, resulting in packet drops.\n\nAccording to RFC 4301 section 4.4.2 , for inbound processing a unicast SA\nis uniquely identified by the SPI and optionally protocol.\n\nReproducing the Issue Reliably:\nTo consistently reproduce the problem, restrict the available SPI range in\ncharon.conf : spi_min = 0x10000000 spi_max = 0x10000002\nThis limits the system to only 2 usable SPI values.\nNext, create more than 2 Child SA. each using unique pair of src/dst address.\nAs soon as the 3rd Child SA is initiated, it will be assigned a duplicate\nSPI, since the SPI pool is already exhausted.\nWith a narrow SPI range, the issue is consistently reproducible.\nWith a broader/default range, it becomes rare and unpredictable.\n\nCurrent implementation:\nxfrm_spi_hash() lookup function computes hash using daddr, proto, and family.\nSo if two SAs have the same SPI but different destination addresses, then\nthey will:\na. Hash into different buckets\nb. Be stored in different linked lists (byspi + h)\nc. Not be seen in the same hlist_for_each_entry_rcu() iteration.\nAs a result, the lookup will result in NULL and kernel allows that Duplicate SPI\n\nProposed Change:\nxfrm_state_lookup_spi_proto() does a truly global search - across all states,\nregardless of hash bucket and matches SPI and proto.(CVE-2025-39797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().\n\nsyzbot reported the splat below. [0]\n\nWhen atmtcp_v_open() or atmtcp_v_close() is called via connect()\nor close(), atmtcp_send_control() is called to send an in-kernel\nspecial message.\n\nThe message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.\nAlso, a pointer of struct atm_vcc is set to atmtcp_control.vcc.\n\nThe notable thing is struct atmtcp_control is uAPI but has a\nspace for an in-kernel pointer.\n\n struct atmtcp_control {\n \tstruct atmtcp_hdr hdr;\t/* must be first */\n ...\n \tatm_kptr_t vcc;\t\t/* both directions */\n ...\n } __ATM_API_ALIGN;\n\n typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;\n\nThe special message is processed in atmtcp_recv_control() called\nfrom atmtcp_c_send().\n\natmtcp_c_send() is vcc-\u0026gt;dev-\u0026gt;ops-\u0026gt;send() and called from 2 paths:\n\n 1. .ndo_start_xmit() (vcc-\u0026gt;send() == atm_send_aal0())\n 2. vcc_sendmsg()\n\nThe problem is sendmsg() does not validate the message length and\nuserspace can abuse atmtcp_recv_control() to overwrite any kptr\nby atmtcp_control.\n\nLet\u0026apos;s add a new -\u0026gt;pre_send() hook to validate messages from sendmsg().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI\nKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]\nCPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]\nRIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297\nCode: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c\nRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203\nRAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c\nRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd\nR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000\nR13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff\nFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n ____sys_sendmsg+0x505/0x830 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f8d7e96a4a9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9\nRDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005\nRBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f\nR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac\nR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250\n \u0026lt;/TASK\u0026gt;\nModules linked in:(CVE-2025-39828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n CPU1 CPU2 (close())\n ---- ----\n sock_hold(sk) sock_hold(sk);\n lock_sock(sk) \u0026lt;-- block close()\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- refcnt by bt_accept_enqueue()\n release_sock(sk)\n lock_sock(sk)\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- last refcnt\n bt_accept_unlink(sk) \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #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\nCall Trace:\n \u0026lt;TASK\u0026gt;\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:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-\u0026gt;cork.\n\nsyzbot reported the splat below. [0]\n\nThe repro does the following:\n\n 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)\n 2. Attach the prog to a SOCKMAP\n 3. Add a socket to the SOCKMAP\n 4. Activate fault injection\n 5. Send data less than cork_bytes\n\nAt 5., the data is carried over to the next sendmsg() as it is\nsmaller than the cork_bytes specified by bpf_msg_cork_bytes().\n\nThen, tcp_bpf_send_verdict() tries to allocate psock-\u0026gt;cork to hold\nthe data, but this fails silently due to fault injection + __GFP_NOWARN.\n\nIf the allocation fails, we need to revert the sk-\u0026gt;sk_forward_alloc\nchange done by sk_msg_alloc().\n\nLet\u0026apos;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate\npsock-\u0026gt;cork.\n\nThe \u0026quot;*copied\u0026quot; also needs to be updated such that a proper error can\nbe returned to the caller, sendmsg. It fails to allocate psock-\u0026gt;cork.\nNothing has been corked so far, so this patch simply sets \u0026quot;*copied\u0026quot;\nto 0.\n\n[0]:\nWARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983\nModules linked in:\nCPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156\nCode: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 \u0026lt;0f\u0026gt; 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc\nRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246\nRAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80\nRDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000\nRBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4\nR10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380\nR13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872\nFS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __sk_destruct+0x86/0x660 net/core/sock.c:2339\n rcu_do_batch kernel/rcu/tree.c:2605 [inline]\n rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861\n handle_softirqs+0x286/0x870 kernel/softirq.c:579\n __do_softirq kernel/softirq.c:613 [inline]\n invoke_softirq kernel/softirq.c:453 [inline]\n __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:696\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052\n \u0026lt;/IRQ\u0026gt;(CVE-2025-39913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup) | CPU 1 (delayed work callback)\ncnic_netdev_event() |\n cnic_stop_hw() | cnic_delete_task()\n cnic_cm_stop_bnx2x_hw() | ...\n cancel_delayed_work() | /* the queue_delayed_work()\n flush_workqueue() | executes after flush_workqueue()*/\n | queue_delayed_work()\n cnic_free_dev(dev)//free | cnic_delete_task() //new instance\n | dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays \u2014 such as inserting calls to ssleep()\nwithin the cnic_delete_task() function \u2014 to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: Defer ip_vs_ftp unregister during netns cleanup\n\nOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp\nbefore connections with valid cp-\u0026gt;app pointers are flushed, leading to a\nuse-after-free.\n\nFix this by introducing a global `exiting_module` flag, set to true in\nip_vs_ftp_exit() before unregistering the pernet subsystem. In\n__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns\ncleanup (when exiting_module is false) and defer it to\n__ip_vs_cleanup_batch(), which unregisters all apps after all connections\nare flushed. If called during module exit, unregister ip_vs_ftp\nimmediately.(CVE-2025-40018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0026apos;t leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn\u0026apos;t point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\u0026quot;VFS: don\u0026apos;t keep disconnected dentries on d_anon\u0026quot;)\nwhich removed adding of most disconnected dentries to sb-\u0026gt;s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn\u0026apos;t marked as disconnected, as in the\nscenario described above, the reclaim doesn\u0026apos;t happen and the dentries\nare \u0026quot;leaked\u0026quot;. Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \u0026quot;Busy\ninodes after unmount\u0026quot; bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.(CVE-2025-40105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete x-\u0026gt;tunnel as we delete x\n\nThe ipcomp fallback tunnels currently get deleted (from the various\nlists and hashtables) as the last user state that needed that fallback\nis destroyed (not deleted). If a reference to that user state still\nexists, the fallback state will remain on the hashtables/lists,\ntriggering the WARN in xfrm_state_fini. Because of those remaining\nreferences, the fix in commit f75a2804da39 (\u0026quot;xfrm: destroy xfrm_state\nsynchronously on net exit path\u0026quot;) is not complete.\n\nWe recently fixed one such situation in TCP due to defered freeing of\nskbs (commit 9b6412e6979f (\u0026quot;tcp: drop secpath at the same time as we\ncurrently drop dst\u0026quot;)). This can also happen due to IP reassembly: skbs\nwith a secpath remain on the reassembly queue until netns\ndestruction. If we can\u0026apos;t guarantee that the queues are flushed by the\ntime xfrm_state_fini runs, there may still be references to a (user)\nxfrm_state, preventing the timely deletion of the corresponding\nfallback state.\n\nInstead of chasing each instance of skbs holding a secpath one by one,\nthis patch fixes the issue directly within xfrm, by deleting the\nfallback state as soon as the last user state depending on it has been\ndeleted. Destruction will still happen when the final reference is\ndropped.\n\nA separate lockdep class for the fallback state is required since\nwe\u0026apos;re going to lock x-\u0026gt;tunnel while x is locked.(CVE-2025-40215)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u0026gt;dev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026amp;proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026amp;proc_subdir_lock);\n [time window] | rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n | write_unlock(\u0026amp;proc_subdir_lock);\n read_lock(\u0026amp;proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)(CVE-2025-40271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_mon_reinit_self().\n\nsyzbot reported use-after-free of tipc_net(net)-\u0026gt;monitors[]\nin tipc_mon_reinit_self(). [0]\n\nThe array is protected by RTNL, but tipc_mon_reinit_self()\niterates over it without RTNL.\n\ntipc_mon_reinit_self() is called from tipc_net_finalize(),\nwhich is always under RTNL except for tipc_net_finalize_work().\n\nLet\u0026apos;s hold RTNL in tipc_net_finalize_work().\n\n[0]:\nBUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\nBUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162\nRead of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989\n\nCPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025\nWorkqueue: events tipc_net_finalize_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568\n kasan_check_byte include/linux/kasan.h:399 [inline]\n lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162\n rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline]\n rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline]\n rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244\n rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243\n write_lock_bh include/linux/rwlock_rt.h:99 [inline]\n tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718\n tipc_net_finalize+0x115/0x190 net/tipc/net.c:140\n process_one_work kernel/workqueue.c:3236 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400\n kthread+0x70e/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 6089:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657\n tipc_enable_bearer net/tipc/bearer.c:357 [inline]\n __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047\n __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline]\n tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393\n tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline]\n tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321\n genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:729\n ____sys_sendmsg+0x508/0x820 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/\n---truncated---(CVE-2025-40280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: use lock accessing port_state and rport state\n\nnvme_fc_unregister_remote removes the remote port on a lport object at\nany point in time when there is no active association. This races with\nwith the reconnect logic, because nvme_fc_create_association is not\ntaking a lock to check the port_state and atomically increase the\nactive count on the rport.(CVE-2025-40342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Fix incorrect error check in topology_parse_cpu_capacity()\n\nFix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()\nwhich causes the code to proceed with NULL clock pointers. The current\nlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both\nvalid pointers and NULL, leading to potential NULL pointer dereference\nin clk_get_rate().\n\nPer include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:\n\u0026quot;The error code within @ptr if it is an error pointer; 0 otherwise.\u0026quot;\n\nThis means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL\npointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)\nwhen cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be\ncalled when of_clk_get() returns NULL.\n\nReplace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid\npointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup\n\nRaw IP packets have no MAC header, leaving skb-\u0026gt;mac_header uninitialized.\nThis can trigger kernel panics on ARM64 when xfrm or other subsystems\naccess the offset due to strict alignment checks.\n\nInitialize the MAC header to prevent such crashes.\n\nThis can trigger kernel panics on ARM when running IPsec over the\nqmimux0 interface.\n\nExample trace:\n\n Internal error: Oops: 000000009600004f [#1] SMP\n CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1\n Hardware name: LS1028A RDB Board (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : xfrm_input+0xde8/0x1318\n lr : xfrm_input+0x61c/0x1318\n sp : ffff800080003b20\n Call trace:\n xfrm_input+0xde8/0x1318\n xfrm6_rcv+0x38/0x44\n xfrm6_esp_rcv+0x48/0xa8\n ip6_protocol_deliver_rcu+0x94/0x4b0\n ip6_input_finish+0x44/0x70\n ip6_input+0x44/0xc0\n ipv6_rcv+0x6c/0x114\n __netif_receive_skb_one_core+0x5c/0x8c\n __netif_receive_skb+0x18/0x60\n process_backlog+0x78/0x17c\n __napi_poll+0x38/0x180\n net_rx_action+0x168/0x2f0(CVE-2025-68192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix potential use-after-free in have_mon_and_osd_map()\n\nThe wait loop in __ceph_open_session() can race with the client\nreceiving a new monmap or osdmap shortly after the initial map is\nreceived. Both ceph_monc_handle_map() and handle_one_map() install\na new map immediately after freeing the old one\n\n kfree(monc-\u0026gt;monmap);\n monc-\u0026gt;monmap = monmap;\n\n ceph_osdmap_destroy(osdc-\u0026gt;osdmap);\n osdc-\u0026gt;osdmap = newmap;\n\nunder client-\u0026gt;monc.mutex and client-\u0026gt;osdc.lock respectively, but\nbecause neither is taken in have_mon_and_osd_map() it\u0026apos;s possible for\nclient-\u0026gt;monc.monmap-\u0026gt;epoch and client-\u0026gt;osdc.osdmap-\u0026gt;epoch arms in\n\n client-\u0026gt;monc.monmap \u0026amp;\u0026amp; client-\u0026gt;monc.monmap-\u0026gt;epoch \u0026amp;\u0026amp;\n client-\u0026gt;osdc.osdmap \u0026amp;\u0026amp; client-\u0026gt;osdc.osdmap-\u0026gt;epoch;\n\ncondition to dereference an already freed map. This happens to be\nreproducible with generic/395 and generic/397 with KASAN enabled:\n\n BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70\n Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305\n CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n have_mon_and_osd_map+0x56/0x70\n ceph_open_session+0x182/0x290\n ceph_get_tree+0x333/0x680\n vfs_get_tree+0x49/0x180\n do_new_mount+0x1a3/0x2d0\n path_mount+0x6dd/0x730\n do_mount+0x99/0xe0\n __do_sys_mount+0x141/0x180\n do_syscall_64+0x9f/0x100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 13305:\n ceph_osdmap_alloc+0x16/0x130\n ceph_osdc_init+0x27a/0x4c0\n ceph_create_client+0x153/0x190\n create_fs_client+0x50/0x2a0\n ceph_get_tree+0xff/0x680\n vfs_get_tree+0x49/0x180\n do_new_mount+0x1a3/0x2d0\n path_mount+0x6dd/0x730\n do_mount+0x99/0xe0\n __do_sys_mount+0x141/0x180\n do_syscall_64+0x9f/0x100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n Freed by task 9475:\n kfree+0x212/0x290\n handle_one_map+0x23c/0x3b0\n ceph_osdc_handle_map+0x3c9/0x590\n mon_dispatch+0x655/0x6f0\n ceph_con_process_message+0xc3/0xe0\n ceph_con_v1_try_read+0x614/0x760\n ceph_con_workfn+0x2de/0x650\n process_one_work+0x486/0x7c0\n process_scheduled_works+0x73/0x90\n worker_thread+0x1c8/0x2a0\n kthread+0x2ec/0x300\n ret_from_fork+0x24/0x40\n ret_from_fork_asm+0x1a/0x30\n\nRewrite the wait loop to check the above condition directly with\nclient-\u0026gt;monc.mutex and client-\u0026gt;osdc.lock taken as appropriate. While\nat it, improve the timeout handling (previously mount_timeout could be\nexceeded in case wait_event_interruptible_timeout() slept more than\nonce) and access client-\u0026gt;auth_err under client-\u0026gt;monc.mutex to match\nhow it\u0026apos;s set in finish_auth().\n\nmonmap_show() and osdmap_show() now take the respective lock before\naccessing the map as well.(CVE-2025-68285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()\n\nrlen value is a user-controlled value, but dtv5100_i2c_msg() does not\ncheck the size of the rlen value. Therefore, if it is set to a value\nlarger than sizeof(st-\u0026gt;data), an out-of-bounds vuln occurs for st-\u0026gt;data.\n\nTherefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cm: Fix leaking the multicast GID table reference\n\nIf the CM ID is destroyed while the CM event for multicast creating is\nstill queued the cancel_work_sync() will prevent the work from running\nwhich also prevents destroying the ah_attr. This leaks a refcount and\ntriggers a WARN:\n\n GID entry ref leak for dev syz1 index 2 ref=573\n WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]\n WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886\n\nDestroy the ah_attr after canceling the work, it is safe to call this\ntwice.(CVE-2025-71084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: fix check for port enabled in team_queue_override_port_prio_changed()\n\nThere has been a syzkaller bug reported recently with the following\ntrace:\n\nlist_del corruption, ffff888058bea080-\u0026gt;prev is LIST_POISON2 (dead000000000122)\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:59!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nCPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #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:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59\nCode: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 \u0026lt;0f\u0026gt; 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286\nRAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000\nRDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005\nRBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230\nR13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480\nFS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __list_del_entry_valid include/linux/list.h:132 [inline]\n __list_del_entry include/linux/list.h:223 [inline]\n list_del_rcu include/linux/rculist.h:178 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline]\n team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline]\n team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534\n team_option_set drivers/net/team/team_core.c:376 [inline]\n team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653\n genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684\n __sys_sendmsg+0x16d/0x220 net/socket.c:2716\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe problem is in this flow:\n1) Port is enabled, queue_id != 0, in qom_list\n2) Port gets disabled\n -\u0026gt; team_port_disable()\n -\u0026gt; team_queue_override_port_del()\n -\u0026gt; del (removed from list)\n3) Port is disabled, queue_id != 0, not in any list\n4) Priority changes\n -\u0026gt; team_queue_override_port_prio_changed()\n -\u0026gt; checks: port disabled \u0026amp;\u0026amp; queue_id != 0\n -\u0026gt; calls del - hits the BUG as it is removed already\n\nTo fix this, change the check in team_queue_override_port_prio_changed()\nso it returns early if port is not enabled.(CVE-2025-71091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf\n\nA zero length gss_token results in pages == 0 and in_token-\u0026gt;pages[0]\nis NULL. The code unconditionally evaluates\npage_address(in_token-\u0026gt;pages[0]) for the initial memcpy, which can\ndereference NULL even when the copy length is 0. Guard the first\nmemcpy so it only runs when length \u0026gt; 0.(CVE-2025-71120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\u0026quot;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\u0026quot;)\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command\u0026apos;s data structures (cmd-\u0026gt;req.sg and cmd-\u0026gt;iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT \u2192 both pointers NULL\n2. H2C_DATA PDU for READ command \u2192 cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n3. H2C_DATA PDU for uninitialized command slot \u2192 both pointers NULL\n\nThe fix validates both cmd-\u0026gt;req.sg and cmd-\u0026gt;iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n- WRITE commands: both allocated(CVE-2026-22998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()\n\nIn nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,\nthe function jumps to the out_scratch label without freeing the already\nallocated dsaddrs list, leading to a memory leak.\n\nFix this by jumping to the out_err_drain_dsaddrs label, which properly\nfrees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)",
"id": "OESA-2026-1341",
"modified": "2026-08-06T11:10:22Z",
"published": "2026-02-13T11:10:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1341"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50151"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50159"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53521"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53594"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53712"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53179"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37766"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37770"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38480"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38572"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38574"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38618"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39797"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40215"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40346"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71120"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23038"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49190",
"CVE-2022-49309",
"CVE-2022-49829",
"CVE-2022-50151",
"CVE-2022-50159",
"CVE-2022-50616",
"CVE-2022-50735",
"CVE-2023-52927",
"CVE-2023-53250",
"CVE-2023-53254",
"CVE-2023-53521",
"CVE-2023-53594",
"CVE-2023-53712",
"CVE-2023-53840",
"CVE-2023-54048",
"CVE-2023-54145",
"CVE-2023-54321",
"CVE-2024-53179",
"CVE-2025-21981",
"CVE-2025-23138",
"CVE-2025-37766",
"CVE-2025-37770",
"CVE-2025-37947",
"CVE-2025-38068",
"CVE-2025-38154",
"CVE-2025-38250",
"CVE-2025-38480",
"CVE-2025-38556",
"CVE-2025-38572",
"CVE-2025-38574",
"CVE-2025-38618",
"CVE-2025-38676",
"CVE-2025-38728",
"CVE-2025-39676",
"CVE-2025-39702",
"CVE-2025-39744",
"CVE-2025-39749",
"CVE-2025-39797",
"CVE-2025-39828",
"CVE-2025-39853",
"CVE-2025-39860",
"CVE-2025-39913",
"CVE-2025-39945",
"CVE-2025-40018",
"CVE-2025-40105",
"CVE-2025-40215",
"CVE-2025-40271",
"CVE-2025-40280",
"CVE-2025-40342",
"CVE-2025-40346",
"CVE-2025-68192",
"CVE-2025-68285",
"CVE-2025-68819",
"CVE-2025-71084",
"CVE-2025-71091",
"CVE-2025-71120",
"CVE-2026-22998",
"CVE-2026-23038"
]
}
OESA-2026-1759 (CVE-2024-53232)
Vulnerability from osv_openeuler – Published: 2026-03-27 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Implement blocking domain
This fixes a crash when surprise hot-unplugging a PCI device. This crash happens because during hot-unplug __iommu_group_set_domain_nofail() attaching the default domain fails when the platform no longer recognizes the device as it has already been removed and we end up with a NULL domain pointer and UAF. This is exactly the case referred to in the second comment in __iommu_device_set_domain() and just as stated there if we can instead attach the blocking domain the UAF is prevented as this can handle the already removed device. Implement the blocking domain to use this handling. With this change, the crash is fixed but we still hit a warning attempting to change DMA ownership on a blocked device.(CVE-2024-53232)
In the Linux kernel, the following vulnerability has been resolved:
iommu: Fix two issues in iommu_copy_struct_from_user()
In the review for iommu_copy_struct_to_user() helper, Matt pointed out that a NULL pointer should be rejected prior to dereferencing it: https://lore.kernel.org/all/(CVE-2025-37900)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Avoid race in open_cached_dir with lease breaks
A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs.
Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked.(CVE-2025-37954)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: prio: fix a race in prio_tune()
Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 1: lock root
[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.(CVE-2025-38083)
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix potential deadlock in MR deregistration
The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock.
The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | → revoke_mr() | → mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | → mutex_lock(&dev->cache.rb_lock) | → mlx5r_cache_create_ent_locked() | → kzalloc(GFP_KERNEL) | → fs_reclaim() | → mmu_notifier_invalidate_range_start() | → mlx5_ib_invalidate_range() | → mutex_lock(&umem_odp->umem_mutex) → cache_ent_find_and_store() | → mutex_lock(&dev->cache.rb_lock) |
Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex.
Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path.
This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path.
The following lockdep warning demonstrates the deadlock:
python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]
but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138
-> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
-> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core]
---truncated---(CVE-2025-38373)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Harden s32ton() against conversion to 0 bits
Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that.
Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.(CVE-2025-38556)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject narrower access to pointer ctx fields
The following BPF program, simplified from a syzkaller repro, causes a kernel warning:
r0 = *(u8 *)(r1 + 169);
exit;
With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the "is_narrower_load" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning:
verifier bug: error during ctx access conversion(1)
This patch fixes that to return a proper "invalid bpf_context access off=X size=Y" error on the load instruction.
The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency.
Note this syzkaller crash was reported in the "Closes" link below, which used to be about a different bug, fixed in commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.(CVE-2025-38591)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: No more self recovery
When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw.
However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 ("gfs2: Prevent double iput for journal on error") and is a NULL pointer dereference since then.
Simply get rid of self recovery to fix that.(CVE-2025-38659)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/net: commit partial buffers on retry
Ring provided buffers are potentially only valid within the single execution context in which they were acquired. io_uring deals with this and invalidates them on retry. But on the networking side, if MSG_WAITALL is set, or if the socket is of the streaming type and too little was processed, then it will hang on to the buffer rather than recycle or commit it. This is problematic for two reasons:
1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid.
2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer.
Fix this by disallowing partial retries from pinning a provided buffer across multiple executions, if ring provided buffers are used.(CVE-2025-38730)
In the Linux kernel, the following vulnerability has been resolved:
media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()
In the interrupt handler rain_interrupt(), the buffer full check on rain->buf_len is performed before acquiring rain->buf_lock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buf_len is concurrently accessed and modified in the work handler rain_irq_work_handler() under the same lock.
Multiple interrupt invocations can race, with each reading buf_len before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buf_len beyond its capacity (DATA_SIZE) and causing a buffer overflow.
Fix this bug by moving the spin_lock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spin_unlock() is added to the overflow path to correctly release the lock.
This possible bug was found by an experimental static analysis tool developed by our team.(CVE-2025-39713)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd/pgtbl: Fix possible race while increase page table level
The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations.
The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level.
But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON.
CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)
Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.(CVE-2025-39961)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: check the return value of pinmux_ops::get_function_name()
While the API contract in docs doesn't specify it explicitly, the generic implementation of the get_function_name() callback from struct pinmux_ops - pinmux_generic_get_function_name() - can fail and return NULL. This is already checked in pinmux_check_ops() so add a similar check in pinmux_func_name_to_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions.(CVE-2025-40030)
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies
When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free.
Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this:
drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; }
for (; i < fence_count; i++)
dma_fence_put(fences[i]);
Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it.
The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").
At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") noticed and attempted to fix.
But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case.
As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain.
While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.(CVE-2025-40096)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete x->tunnel as we delete x
The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.
We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.
Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.
A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.(CVE-2025-40215)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix livelock in synchronous file put from fuseblk workers
I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server:
cat /proc/372265/task/372313/stack
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
But the /weird/ part is that the fuseblk server threads are waiting for responses from itself:
cat /proc/372210/task/372232/stack
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that:
"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands.
Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.(CVE-2025-40220)
In the Linux kernel, the following vulnerability has been resolved:
fs/notify: call exportfs_encode_fid with s_umount
Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr.
This issue was found by syzkaller.
Race Condition Diagram:
Thread 1 Thread 2 -------- --------
generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL
|
| vfs_read()
| inotify_fdinfo()
| * inode get from mark *
| show_mark_fhandle(m, inode)
| exportfs_encode_fid(inode, ..)
| ovl_encode_fh(inode, ..)
| ovl_check_encode_origin(inode)
| * deref i_sb->s_root *
|
|
v
fsnotify_sb_delete(sb)
Which then leads to:
[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)
<snip registers, unreliable trace>
[ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240
IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path.
Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock.
This form of fix was suggested by Amir in 1.
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix unlikely race in gdlm_put_lock
In gdlm_put_lock(), there is a small window of time in which the DFL_UNMOUNT flag has been set but the lockspace hasn't been released, yet. In that window, dlm may still call gdlm_ast() and gdlm_bast(). To prevent it from dereferencing freed glock objects, only free the glock if the lockspace has actually been released.(CVE-2025-40242)
In the Linux kernel, the following vulnerability has been resolved:
devlink: rate: Unset parent pointer in devl_rate_nodes_destroy
The function devl_rate_nodes_destroy is documented to "Unset parent for
all rate objects". However, it was only calling the driver-specific
rate_leaf_parent_set or rate_node_parent_set ops and decrementing
the parent's refcount, without actually setting the
devlink_rate->parent pointer to NULL.
This leaves a dangling pointer in the devlink_rate struct, which cause
refcount error in netdevsim1 and mlx52. In addition, this is
inconsistent with the behavior of devlink_nl_rate_parent_node_set,
where the parent pointer is correctly cleared.
This patch fixes the issue by explicitly setting devlink_rate->parent
to NULL after notifying the driver, thus fulfilling the function's
documented behavior for all rate objects.
1 repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device
dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: <TASK> devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
2 devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core
dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: <TASK> devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-40251)
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |
rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)
In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix use-after-free race in fault handler
When a page fault occurs in a secret memory file created with
memfd_secret(2), the kernel will allocate a new folio for it, mark the
underlying page as not-present in the direct map, and add it to the file
mapping.
If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping.
If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault.
Fix the ordering to restore the direct map before the folio is freed.(CVE-2025-40272)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE
This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.(CVE-2025-40277)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()
In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied.
Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH.
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40294)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: validate skb length for unknown CC opcode
In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory.
The fix is to check skb->len before using skb->data.(CVE-2025-40301)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bcsp: receive data only if registered
Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace:
KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590
Call Trace:
<TASK>
hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627
tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290
tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.(CVE-2025-40308)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and "UAF".
Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.(CVE-2025-40318)
In the Linux kernel, the following vulnerability has been resolved:
futex: Don't leak robust_list pointer on exec race
sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process.
During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged.
A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec().
For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process.
This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk.
Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.(CVE-2025-40341)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: use lock accessing port_state and rport state
nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.(CVE-2025-40342)
In the Linux kernel, the following vulnerability has been resolved:
nvmet-fc: avoid scheduling association deletion twice
When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion.
The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion.
Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.(CVE-2025-40343)
In the Linux kernel, the following vulnerability has been resolved:
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
The syzbot reported issue in hfsplus_delete_cat():
[ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] slaballoc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] ---truncated---(CVE-2025-40351)
In the Linux kernel, the following vulnerability has been resolved:
riscv: stacktrace: Disable KASAN checks for non-current tasks
Unwinding the stack of a task other than current, KASAN would report "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"
There is a same issue on x86 and has been resolved by the commit 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks") The solution could be applied to RISC-V too.
This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23
[(CVE-2025-40358)
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Fix KASAN global-out-of-bounds warning
When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen.
================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850
Call Trace:
kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80
The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF.
WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)
So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue.(CVE-2025-40359)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-40361)
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Ensure XFD state on signal delivery
Sean reported 1 the following splat when running KVM tests:
WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Chao further identified 2 a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR.
When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption.
Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature.
This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible.
dhansen: minor changelog munging
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix softlockup in ftrace_module_enable
A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()").
Fix it the same way by adding cond_resched() in ftrace_module_enable.(CVE-2025-68173)
In the Linux kernel, the following vulnerability has been resolved:
amd/amdkfd: enhance kfd process check in switch partition
current switch partition only check if kfd_processes_table is empty. kfd_prcesses_table entry is deleted in kfd_process_notifier_release, but kfd_process tear down is in kfd_process_wq_release.
consider two processes:
Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node member Process B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw -> kfd_node tear down.
Process A and B may trigger a race as shown in dmesg log.
This patch is to resolve the race by adding an atomic kfd_process counter kfd_processes_count, it increment as create kfd process, decrement as finish kfd_process_wq_release.
v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds and bug fix. (Philip Yang)
[3966658.307702] divide error: 0000 [#1] SMP NOPTI [3966658.350818] i10nm_edac [3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted [3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] [3966658.362839] nfit [3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu] [3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 <f7> be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00 [3966658.380967] x86_pkg_temp_thermal [3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246 [3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000 [3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00 [3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4 [3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000 [3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800 [3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000 [3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0 [3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [3966658.391536] PKRU: 55555554 [3966658.391536] Call Trace: [3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu] [3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu] [3966658.399754] intel_powerclamp [3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu] [3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu] [3966658.410516] coretemp [3966658.434016] process_one_work+0x1ad/0x380 [3966658.434021] worker_thread+0x49/0x310 [3966658.438963] kvm_intel [3966658.446041] ? process_one_work+0x380/0x380 [3966658.446045] kthread+0x118/0x140 [3966658.446047] ? __kthread_bind_mask+0x60/0x60 [3966658.446050] ret_from_fork+0x1f/0x30 [3966658.446053] Modules linked in: kpatch_20765354(OEK) [3966658.455310] kvm [3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK) [3966658.473462] idxd_mdev [3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo ---truncated---(CVE-2025-68174)
In the Linux kernel, the following vulnerability has been resolved:
PCI: cadence: Check for the existence of cdns_pcie::ops before using it
cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops.
Hence, add a check to prevent NULL pointer dereference.
mani: reworded subject and description
In the Linux kernel, the following vulnerability has been resolved:
tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()
Use RCU to avoid a pair of atomic operations and a potential UAF on dst_dev()->flags.(CVE-2025-68188)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Add bpf_prog_run_data_pointers()
syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().
WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214
struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and data_end for cls_act_bpf").
drop_reason was added later.
Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end.(CVE-2025-68200)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: add seqadj extension for natted connections
Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq.
The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet }
chain prerouting {
type filter hook prerouting priority 0; policy accept;
tcp dport 21 ct state new ct helper set "ftp_helper"
}
} table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } }
chain postrouting {
type nat hook postrouting priority 100 ; policy accept;
tcp sport 21 snat ip prefix to ip saddr map {
192.168.13.2 : 192.168.100.1/32 }
}
}
Note that the ftp helper gets assigned after the dnat setup.
The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem.
Topoloy:
+-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+
ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection.
Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..
Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.(CVE-2025-68206)
In the Linux kernel, the following vulnerability has been resolved:
bpf: account for current allocated stack depth in widen_imprecise_scalars()
The usage pattern for widen_imprecise_scalars() looks as follows:
prev_st = find_prev_entry(env, ...);
queued_st = push_stack(...);
widen_imprecise_scalars(env, prev_st, queued_st);
Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case:
def main():
for i in 1..2:
foo(i) // same callsite, differnt param
def foo(i):
if i == 1:
use 128 bytes of stack
iterator based loop
Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds.(CVE-2025-68208)
In the Linux kernel, the following vulnerability has been resolved:
timers: Fix NULL function pointer race in timer_shutdown_sync()
There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers().
The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:
CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base()
The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers().
Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.(CVE-2025-68214)
In the Linux kernel, the following vulnerability has been resolved:
nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot
nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning.
Make sure this data is deallocated.(CVE-2025-68235)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced
When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn instruction, discard the exception and retry the instruction if the code stream is changed (e.g. by a different vCPU) between when the CPU executes the instruction and when KVM decodes the instruction to get the next RIP.
As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction"), failure to verify that the correct INTn instruction was decoded can effectively clobber guest state due to decoding the wrong instruction and thus specifying the wrong next RIP.
The bug most often manifests as "Oops: int3" panics on static branch checks in Linux guests. Enabling or disabling a static branch in Linux uses the kernel's "text poke" code patching mechanism. To modify code while other CPUs may be executing that code, Linux (temporarily) replaces the first byte of the original instruction with an int3 (opcode 0xcc), then patches in the new code stream except for the first byte, and finally replaces the int3 with the first byte of the new code stream. If a CPU hits the int3, i.e. executes the code while it's being modified, then the guest kernel must look up the RIP to determine how to handle the #BP, e.g. by emulating the new instruction. If the RIP is incorrect, then this lookup fails and the guest kernel panics.
The bug reproduces almost instantly by hacking the guest kernel to repeatedly check a static branch1 while running a drgn script2 on the host to constantly swap out the memory containing the guest's TSS.
In the Linux kernel, the following vulnerability has been resolved:
ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()
Fix a race between inline data destruction and block mapping.
The function ext4_destroy_inline_data_nolock() changes the inode data layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS. At the same time, another thread may execute ext4_map_blocks(), which tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks() or ext4_ind_map_blocks().
Without i_data_sem protection, ext4_ind_map_blocks() may receive inode with EXT4_INODE_EXTENTS flag and triggering assert.
kernel BUG at fs/ext4/indirect.c:546! EXT4-fs (loop2): unmounting filesystem. invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546
Call Trace: <TASK> ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2025-68261)
In the Linux kernel, the following vulnerability has been resolved:
ext4: refresh inline data size before write operations
The cached ei->i_inline_size can become stale between the initial size check and when ext4_update_inline_data()/ext4_create_inline_data() use it. Although ext4_get_max_inline_size() reads the correct value at the time of the check, concurrent xattr operations can modify i_inline_size before ext4_write_lock_xattr() is acquired.
This causes ext4_update_inline_data() and ext4_create_inline_data() to work with stale capacity values, leading to a BUG_ON() crash in ext4_write_inline_data():
kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
The race window: 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, i_inline_size changes to 40] 4. ext4_write_lock_xattr() acquires lock 5. ext4_update_inline_data() uses stale i_inline_size = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers
Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock() immediately after acquiring xattr_sem. This ensures ext4_update_inline_data() and ext4_create_inline_data() work with current values that are protected from concurrent modifications.
This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inline_data file while its xattrs are changing") which fixed i_inline_off staleness. This patch addresses the related i_inline_size staleness issue.(CVE-2025-68264)
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix admin request_queue lifetime
The namespaces can access the controller's admin request_queue, and stale references on the namespaces may exist after tearing down the controller. Ensure the admin request_queue is active by moving the controller's 'put' to after all controller references have been released to ensure no one is can access the request_queue. This fixes a reported use-after-free bug:
BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNED_MODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: <TASK> dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ? _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 ? blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 ? wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0 ? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 ? cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380 __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60 </TASK>(CVE-2025-68265)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix crash in process_v2_sparse_read() for encrypted directories
The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps:
sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure
(1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered
[ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] <TASK> [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] </TASK> [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---(CVE-2025-68297)
In the Linux kernel, the following vulnerability has been resolved:
PCI/AER: Fix NULL pointer access by aer_info
The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info->xxx will result in kernel panic. Fix it.(CVE-2025-68309)
In the Linux kernel, the following vulnerability has been resolved:
usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer
When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed.
The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed.
This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs().
The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().(CVE-2025-68331)
In the Linux kernel, the following vulnerability has been resolved:
jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted
There's issue when file system corrupted: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1289! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0 RSP: 0018:ffff888117aafa30 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534 RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010 RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028 R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0 Call Trace: <TASK> __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The above issue occurs with us in errors=continue mode when accompanied by storage failures. There have been many inconsistencies in the file system data. In the case of file system data inconsistency, for example, if the block bitmap of a referenced block is not set, it can lead to the situation where a block being committed is allocated and used again. As a result, the following condition will not be satisfied then trigger BUG_ON. Of course, it is entirely possible to construct a problematic image that can trigger this BUG_ON through specific operations. In fact, I have constructed such an image and easily reproduced this issue. Therefore, J_ASSERT() holds true only under ideal conditions, but it may not necessarily be satisfied in exceptional scenarios. Using J_ASSERT() directly in abnormal situations would cause the system to crash, which is clearly not what we want. So here we directly trigger a JBD abort instead of immediately invoking BUG_ON.(CVE-2025-68337)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid
Fixes a crash when layout is null during this call stack:
write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode
pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.(CVE-2025-68349)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to:
1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.
Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Prevent recursive memory reclaim
Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory.
Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue.
To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS.
The "meta" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt.
This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation").
Fixes xfstest generic/273.(CVE-2025-68356)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()
The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header.
If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic.
Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.(CVE-2025-68362)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check skb->transport_header is set in bpf_skb_check_mtu
The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used:
bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)
The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used:
WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb
For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").
This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.(CVE-2025-68363)
In the Linux kernel, the following vulnerability has been resolved:
coresight: ETR: Fix ETR buffer use-after-free issue
When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue.
Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.(CVE-2025-68376)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stackmap overflow check in __bpf_get_stackid()
Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.(CVE-2025-68378)
In the Linux kernel, the following vulnerability has been resolved:
crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id
Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.(CVE-2025-68724)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do not let BPF test infra emit invalid GSO types to stack
Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled.
We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place.
The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.(CVE-2025-68725)
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()
In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style.
Compile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix improper freeing of purex item
In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item().
The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc().
An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption.
Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.(CVE-2025-68741)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Free special fields when update [lru_,]percpu_hash maps
As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed.
Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value,_long' in 'pcpu_copy_value()'.(CVE-2025-68744)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Clear cmds after chip reset
Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems:
-
Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.
-
BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().
So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at __qla2x00_abort_all_cmds.(CVE-2025-68745)
In the Linux kernel, the following vulnerability has been resolved:
block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock
blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared.
Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also.
This results in deadlock between two threads with these stacktraces:
__schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20
__schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53
The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list.
The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever.
Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.(CVE-2025-68756)
In the Linux kernel, the following vulnerability has been resolved:
sched/deadline: only set free_cpus for online runqueues
Commit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpus to reflect rd->online") introduced the cpudl_set/clear_freecpu functions to allow the cpu_dl::free_cpus mask to be manipulated by the deadline scheduler class rq_on/offline callbacks so the mask would also reflect this state.
Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_mask from cpudl_find()") removed the check of the cpu_active_mask to save some processing on the premise that the cpudl::free_cpus mask already reflected the runqueue online state.
Unfortunately, there are cases where it is possible for the cpudl_clear function to set the free_cpus bit for a CPU when the deadline runqueue is offline. When this occurs while a CPU is connected to the default root domain the flag may retain the bad state after the CPU has been unplugged. Later, a different CPU that is transitioning through the default root domain may push a deadline task to the powered down CPU when cpudl_find sees its free_cpus bit is set. If this happens the task will not have the opportunity to run.
One example is outlined here: https://lore.kernel.org/lkml/(CVE-2025-68780)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: Reset t_task_cdb pointer in error case
If allocation of cmd->t_task_cdb fails, it remains NULL but is later dereferenced in the 'err' path.
In case of error, reset NULL t_task_cdb value to point at the default fixed-size buffer.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68782)
In the Linux kernel, the following vulnerability has been resolved:
iomap: adjust read range correctly for non-block-aligned positions
iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio.
Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.(CVE-2025-68794)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: NFSv4 file creation neglects setting ACL
An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: "the ACL attribute is set as given".
The issue occurs in nfsd_create_setattr(), which calls nfsd_attrs_valid() to determine whether to call nfsd_setattr(). However, nfsd_attrs_valid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsd_setattr() is skipped, and the POSIX ACL is never applied to the inode.
Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL.(CVE-2025-68803)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix filename leak in __io_openat_prep()
__io_openat_prep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak.
Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup.(CVE-2025-68814)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: fw_tracer, Validate format string parameters
Add validation for format string parameters in the firmware tracer to prevent potential security vulnerabilities and crashes from malformed format strings received from firmware.
The firmware tracer receives format strings from the device firmware and uses them to format trace messages. Without proper validation, bad firmware could provide format strings with invalid format specifiers (e.g., %s, %p, %n) that could lead to crashes, or other undefined behavior.
Add mlx5_tracer_validate_params() to validate that all format specifiers in trace strings are limited to safe integer/hex formats (%x, %d, %i, %u, %llx, %lx, etc.). Reject strings containing other format types that could be used to access arbitrary memory or cause crashes. Invalid format strings are added to the trace output for visibility with "BAD_FORMAT: " prefix.(CVE-2025-68816)
In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"
This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.
The commit being reverted added code to __qla2x00_abort_all_cmds() to call sp->done() without holding a spinlock. But unlike the older code below it, this new code failed to check sp->cmd_type and just assumed TYPE_SRB, which results in a jump to an invalid pointer in target-mode with TYPE_TGT_CMD:
qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79b qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h. qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no buffer qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurred qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda. BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor instruction fetch in kernel mode PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1 Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206 RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000 RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0 RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045 R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40 R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400 FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 </TASK>
Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early within lock") added the spinlock back, because not having the lock caused a race and a crash. But qla2x00_abort_srb() in the switch below already checks for qla2x00_chip_is_down() and handles it the same way, so the code above the switch is now redundant and still buggy in target-mode. Remove it.(CVE-2025-68818)
In the Linux kernel, the following vulnerability has been resolved:
shmem: fix recovery on rename failures
maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange().
Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout().
Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton.
For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations.
For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations.
That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().(CVE-2025-71072)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in update_target_expiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 </IRQ>
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---(CVE-2025-71104)
In the Linux kernel, the following vulnerability has been resolved:
libceph: make decode_pool() more resilient against corrupted osdmaps
If the osdmap is (maliciously) corrupted such that the encoded length of ceph_pg_pool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value.
This patch adds explicit bounds checks for each field that is decoded or skipped.(CVE-2025-71116)
In the Linux kernel, the following vulnerability has been resolved:
crypto: seqiv - Do not use req->iv after crypto_aead_encrypt
As soon as crypto_aead_encrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.
Instead of checking req->iv against info, create a new variable unaligned_info and use it for that purpose instead.(CVE-2025-71131)
In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix a memory leak in tpm2_load_cmd
'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode' but it is not freed in the failure paths. Address this by wrapping the blob into with a cleanup helper.(CVE-2025-71147)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: correctly handle io_poll_add() return value on update
When the core of io_uring was updated to handle completions consistently and with fixed return codes, the POLL_REMOVE opcode with updates got slightly broken. If a POLL_ADD is pending and then POLL_REMOVE is used to update the events of that request, if that update causes the POLL_ADD to now trigger, then that completion is lost and a CQE is never posted.
Additionally, ensure that if an update does cause an existing POLL_ADD to complete, that the completion value isn't always overwritten with -ECANCELED. For that case, whatever io_poll_add() set the value to should just be retained.(CVE-2025-71149)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Fix refcount leak when invalid session is found on session lookup
When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.(CVE-2025-71150)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv
mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5e_dev and get mdev from the containing mlx5_adev aux device structure.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_remove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: <TASK> device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-22996)
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec
Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs.
The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.
Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL
The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated(CVE-2026-22998)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix crash on profile change rollback failure
mlx5e_netdev_change_profile can fail to attach a new profile and can fail to rollback to old profile, in such case, we could end up with a dangling netdev with a fully reset netdev_priv. A retry to change profile, e.g. another attempt to call mlx5e_netdev_change_profile via switchdev mode change, will crash trying to access the now NULL priv->mdev.
This fix allows mlx5e_netdev_change_profile() to handle previous failures and an empty priv, by not assuming priv is valid.
Pass netdev and mdev to all flows requiring mlx5e_netdev_change_profile() and avoid passing priv. In mlx5e_netdev_change_profile() check if current priv is valid, and if not, just attach the new profile without trying to access the old one.
This fixes the following oops, when enabling switchdev mode for the 2nd time after first time failure:
## Enabling switchdev mode first time:
mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 ^^^^^^^^ mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)
## retry: Enabling switchdev mode 2nd time:
mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload BUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_detach_netdev+0x3c/0x90 Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdfb8495047(CVE-2026-23000)
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1
When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel.
E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:
------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's call to fpu_update_guest_xfd().
and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:
------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component):
If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).
Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD.
Therefore, XFD can only go out of sync with XSTATE_BV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.
[Move clea ---truncated---(CVE-2026-23005)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv
mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails.
Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a valid netdev.
On mlx5e_remove: Check validity of priv->profile, before attempting to cleanup any resources that might be not there.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0 RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10 R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0 R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400 FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-23035)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add recursion protection in kernel stack trace recording
A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again.
Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI).
Have the stack trace code use the interrupt context to protect against recursion.
Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately.(CVE-2026-23138)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-source-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"perf-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"python3-perf-6.6.0-144.0.0.127.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-144.0.0.127.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-144.0.0.127.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-source-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"perf-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"python3-perf-6.6.0-144.0.0.127.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-144.0.0.127.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-144.0.0.127.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/s390: Implement blocking domain\n\nThis fixes a crash when surprise hot-unplugging a PCI device. This crash\nhappens because during hot-unplug __iommu_group_set_domain_nofail()\nattaching the default domain fails when the platform no longer\nrecognizes the device as it has already been removed and we end up with\na NULL domain pointer and UAF. This is exactly the case referred to in\nthe second comment in __iommu_device_set_domain() and just as stated\nthere if we can instead attach the blocking domain the UAF is prevented\nas this can handle the already removed device. Implement the blocking\ndomain to use this handling. With this change, the crash is fixed but\nwe still hit a warning attempting to change DMA ownership on a blocked\ndevice.(CVE-2024-53232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu: Fix two issues in iommu_copy_struct_from_user()\n\nIn the review for iommu_copy_struct_to_user() helper, Matt pointed out that\na NULL pointer should be rejected prior to dereferencing it:\nhttps://lore.kernel.org/all/(CVE-2025-37900)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Avoid race in open_cached_dir with lease breaks\n\nA pre-existing valid cfid returned from find_or_create_cached_dir might\nrace with a lease break, meaning open_cached_dir doesn\u0026apos;t consider it\nvalid, and thinks it\u0026apos;s newly-constructed. This leaks a dentry reference\nif the allocation occurs before the queued lease break work runs.\n\nAvoid the race by extending holding the cfid_list_lock across\nfind_or_create_cached_dir and when the result is checked.(CVE-2025-37954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: prio: fix a race in prio_tune()\n\nGerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n | [5]: lock root\n | [6]: rehash\n | [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent\u0026apos;s qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.(CVE-2025-38083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix potential deadlock in MR deregistration\n\nThe issue arises when kzalloc() is invoked while holding umem_mutex or\nany other lock acquired under umem_mutex. This is problematic because\nkzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke\nmmu_notifier_invalidate_range_start(). This function can lead to\nmlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,\nresulting in a deadlock.\n\nThe problematic flow:\n CPU0 | CPU1\n---------------------------------------|------------------------------------------------\nmlx5_ib_dereg_mr() |\n \u2192 revoke_mr() |\n \u2192 mutex_lock(\u0026amp;umem_odp-\u0026gt;umem_mutex) |\n | mlx5_mkey_cache_init()\n | \u2192 mutex_lock(\u0026amp;dev-\u0026gt;cache.rb_lock)\n | \u2192 mlx5r_cache_create_ent_locked()\n | \u2192 kzalloc(GFP_KERNEL)\n | \u2192 fs_reclaim()\n | \u2192 mmu_notifier_invalidate_range_start()\n | \u2192 mlx5_ib_invalidate_range()\n | \u2192 mutex_lock(\u0026amp;umem_odp-\u0026gt;umem_mutex)\n \u2192 cache_ent_find_and_store() |\n \u2192 mutex_lock(\u0026amp;dev-\u0026gt;cache.rb_lock) |\n\nAdditionally, when kzalloc() is called from within\ncache_ent_find_and_store(), we encounter the same deadlock due to\nre-acquisition of umem_mutex.\n\nSolve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()\nand before acquiring rb_lock. This ensures that we don\u0026apos;t hold\numem_mutex while performing memory allocations that could trigger\nthe reclaim path.\n\nThis change prevents the deadlock by ensuring proper lock ordering and\navoiding holding locks during memory allocation operations that could\ntrigger the reclaim path.\n\nThe following lockdep warning demonstrates the deadlock:\n\n python3/20557 is trying to acquire lock:\n ffff888387542128 (\u0026amp;umem_odp-\u0026gt;umem_mutex){+.+.}-{4:4}, at:\n mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]\n\n but task is already holding lock:\n ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:\n unmap_vmas+0x7b/0x1a0\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u0026gt; #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:\n fs_reclaim_acquire+0x60/0xd0\n mem_cgroup_css_alloc+0x6f/0x9b0\n cgroup_init_subsys+0xa4/0x240\n cgroup_init+0x1c8/0x510\n start_kernel+0x747/0x760\n x86_64_start_reservations+0x25/0x30\n x86_64_start_kernel+0x73/0x80\n common_startup_64+0x129/0x138\n\n -\u0026gt; #2 (fs_reclaim){+.+.}-{0:0}:\n fs_reclaim_acquire+0x91/0xd0\n __kmalloc_cache_noprof+0x4d/0x4c0\n mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]\n mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]\n mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]\n __mlx5_ib_add+0x4b/0x190 [mlx5_ib]\n mlx5r_probe+0xd9/0x320 [mlx5_ib]\n auxiliary_bus_probe+0x42/0x70\n really_probe+0xdb/0x360\n __driver_probe_device+0x8f/0x130\n driver_probe_device+0x1f/0xb0\n __driver_attach+0xd4/0x1f0\n bus_for_each_dev+0x79/0xd0\n bus_add_driver+0xf0/0x200\n driver_register+0x6e/0xc0\n __auxiliary_driver_register+0x6a/0xc0\n do_one_initcall+0x5e/0x390\n do_init_module+0x88/0x240\n init_module_from_file+0x85/0xc0\n idempotent_init_module+0x104/0x300\n __x64_sys_finit_module+0x68/0xc0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n -\u0026gt; #1 (\u0026amp;dev-\u0026gt;cache.rb_lock){+.+.}-{4:4}:\n __mutex_lock+0x98/0xf10\n __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]\n mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]\n ib_dereg_mr_user+0x85/0x1f0 [ib_core]\n \n---truncated---(CVE-2025-38373)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Harden s32ton() against conversion to 0 bits\n\nTesting by the syzbot fuzzer showed that the HID core gets a\nshift-out-of-bounds exception when it tries to convert a 32-bit\nquantity to a 0-bit quantity. Ideally this should never occur, but\nthere are buggy devices and some might have a report field with size\nset to zero; we shouldn\u0026apos;t reject the report or the device just because\nof that.\n\nInstead, harden the s32ton() routine so that it returns a reasonable\nresult instead of crashing when it is called with the number of bits\nset to 0 -- the same as what snto32() does.(CVE-2025-38556)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject narrower access to pointer ctx fields\n\nThe following BPF program, simplified from a syzkaller repro, causes a\nkernel warning:\n\n r0 = *(u8 *)(r1 + 169);\n exit;\n\nWith pointer field sk being at offset 168 in __sk_buff. This access is\ndetected as a narrower read in bpf_skb_is_valid_access because it\ndoesn\u0026apos;t match offsetof(struct __sk_buff, sk). It is therefore allowed\nand later proceeds to bpf_convert_ctx_access. Note that for the\n\u0026quot;is_narrower_load\u0026quot; case in the convert_ctx_accesses(), the insn-\u0026gt;off\nis aligned, so the cnt may not be 0 because it matches the\noffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,\nthe target_size stays 0 and the verifier errors with a kernel warning:\n\n verifier bug: error during ctx access conversion(1)\n\nThis patch fixes that to return a proper \u0026quot;invalid bpf_context access\noff=X size=Y\u0026quot; error on the load instruction.\n\nThe same issue affects multiple other fields in context structures that\nallow narrow access. Some other non-affected fields (for sk_msg,\nsk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for\nconsistency.\n\nNote this syzkaller crash was reported in the \u0026quot;Closes\u0026quot; link below, which\nused to be about a different bug, fixed in\ncommit fce7bd8e385a (\u0026quot;bpf/verifier: Handle BPF_LOAD_ACQ instructions\nin insn_def_regno()\u0026quot;). Because syzbot somehow confused the two bugs,\nthe new crash and repro didn\u0026apos;t get reported to the mailing list.(CVE-2025-38591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: No more self recovery\n\nWhen a node withdraws and it turns out that it is the only node that has\nthe filesystem mounted, gfs2 currently tries to replay the local journal\nto bring the filesystem back into a consistent state. Not only is that\na very bad idea, it has also never worked because gfs2_recover_func()\nwill refuse to do anything during a withdraw.\n\nHowever, before even getting to this point, gfs2_recover_func()\ndereferences sdp-\u0026gt;sd_jdesc-\u0026gt;jd_inode. This was a use-after-free before\ncommit 04133b607a78 (\u0026quot;gfs2: Prevent double iput for journal on error\u0026quot;)\nand is a NULL pointer dereference since then.\n\nSimply get rid of self recovery to fix that.(CVE-2025-38659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/net: commit partial buffers on retry\n\nRing provided buffers are potentially only valid within the single\nexecution context in which they were acquired. io_uring deals with this\nand invalidates them on retry. But on the networking side, if\nMSG_WAITALL is set, or if the socket is of the streaming type and too\nlittle was processed, then it will hang on to the buffer rather than\nrecycle or commit it. This is problematic for two reasons:\n\n1) If someone unregisters the provided buffer ring before a later retry,\n then the req-\u0026gt;buf_list will no longer be valid.\n\n2) If multiple sockers are using the same buffer group, then multiple\n receives can consume the same memory. This can cause data corruption\n in the application, as either receive could land in the same\n userspace buffer.\n\nFix this by disallowing partial retries from pinning a provided buffer\nacross multiple executions, if ring provided buffers are used.(CVE-2025-38730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()\n\nIn the interrupt handler rain_interrupt(), the buffer full check on\nrain-\u0026gt;buf_len is performed before acquiring rain-\u0026gt;buf_lock. This\ncreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as\nrain-\u0026gt;buf_len is concurrently accessed and modified in the work\nhandler rain_irq_work_handler() under the same lock.\n\nMultiple interrupt invocations can race, with each reading buf_len\nbefore it becomes full and then proceeding. This can lead to both\ninterrupts attempting to write to the buffer, incrementing buf_len\nbeyond its capacity (DATA_SIZE) and causing a buffer overflow.\n\nFix this bug by moving the spin_lock() to before the buffer full\ncheck. This ensures that the check and the subsequent buffer modification\nare performed atomically, preventing the race condition. An corresponding\nspin_unlock() is added to the overflow path to correctly release the\nlock.\n\nThis possible bug was found by an experimental static analysis tool\ndeveloped by our team.(CVE-2025-39713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/pgtbl: Fix possible race while increase page table level\n\nThe AMD IOMMU host page table implementation supports dynamic page table levels\n(up to 6 levels), starting with a 3-level configuration that expands based on\nIOVA address. The kernel maintains a root pointer and current page table level\nto enable proper page table walks in alloc_pte()/fetch_pte() operations.\n\nThe IOMMU IOVA allocator initially starts with 32-bit address and onces its\nexhuasted it switches to 64-bit address (max address is determined based\non IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU\ndriver increases page table level.\n\nBut in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads\npgtable-\u0026gt;[root/mode] without lock. So its possible that in exteme corner case,\nwhen increase_address_space() is updating pgtable-\u0026gt;[root/mode], fetch_pte()\nreads wrong page table level (pgtable-\u0026gt;mode). It does compare the value with\nlevel encoded in page table and returns NULL. This will result is\niommu_unmap ops to fail and upper layer may retry/log WARN_ON.\n\nCPU 0 CPU 1\n------ ------\nmap pages unmap pages\nalloc_pte() -\u0026gt; increase_address_space() iommu_v1_unmap_pages() -\u0026gt; fetch_pte()\n pgtable-\u0026gt;root = pte (new root value)\n READ pgtable-\u0026gt;[mode/root]\n\t\t\t\t\t Reads new root, old mode\n Updates mode (pgtable-\u0026gt;mode += 1)\n\nSince Page table level updates are infrequent and already synchronized with a\nspinlock, implement seqcount to enable lock-free read operations on the read path.(CVE-2025-39961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: check the return value of pinmux_ops::get_function_name()\n\nWhile the API contract in docs doesn\u0026apos;t specify it explicitly, the\ngeneric implementation of the get_function_name() callback from struct\npinmux_ops - pinmux_generic_get_function_name() - can fail and return\nNULL. This is already checked in pinmux_check_ops() so add a similar\ncheck in pinmux_func_name_to_selector() instead of passing the returned\npointer right down to strcmp() where the NULL can get dereferenced. This\nis normal operation when adding new pinfunctions.(CVE-2025-40030)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies\n\nWhen adding dependencies with drm_sched_job_add_dependency(), that\nfunction consumes the fence reference both on success and failure, so in\nthe latter case the dma_fence_put() on the error path (xarray failed to\nexpand) is a double free.\n\nInterestingly this bug appears to have been present ever since\ncommit ebd5f74255b9 (\u0026quot;drm/sched: Add dependency tracking\u0026quot;), since the code\nback then looked like this:\n\ndrm_sched_job_add_implicit_dependencies():\n...\n for (i = 0; i \u0026lt; fence_count; i++) {\n ret = drm_sched_job_add_dependency(job, fences[i]);\n if (ret)\n break;\n }\n\n for (; i \u0026lt; fence_count; i++)\n dma_fence_put(fences[i]);\n\nWhich means for the failing \u0026apos;i\u0026apos; the dma_fence_put was already a double\nfree. Possibly there were no users at that time, or the test cases were\ninsufficient to hit it.\n\nThe bug was then only noticed and fixed after\ncommit 9c2ba265352a (\u0026quot;drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2\u0026quot;)\nlanded, with its fixup of\ncommit 4eaf02d6076c (\u0026quot;drm/scheduler: fix drm_sched_job_add_implicit_dependencies\u0026quot;).\n\nAt that point it was a slightly different flavour of a double free, which\ncommit 963d0b356935 (\u0026quot;drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder\u0026quot;)\nnoticed and attempted to fix.\n\nBut it only moved the double free from happening inside the\ndrm_sched_job_add_dependency(), when releasing the reference not yet\nobtained, to the caller, when releasing the reference already released by\nthe former in the failure case.\n\nAs such it is not easy to identify the right target for the fixes tag so\nlets keep it simple and just continue the chain.\n\nWhile fixing we also improve the comment and explain the reason for taking\nthe reference and not dropping it.(CVE-2025-40096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete x-\u0026gt;tunnel as we delete x\n\nThe ipcomp fallback tunnels currently get deleted (from the various\nlists and hashtables) as the last user state that needed that fallback\nis destroyed (not deleted). If a reference to that user state still\nexists, the fallback state will remain on the hashtables/lists,\ntriggering the WARN in xfrm_state_fini. Because of those remaining\nreferences, the fix in commit f75a2804da39 (\u0026quot;xfrm: destroy xfrm_state\nsynchronously on net exit path\u0026quot;) is not complete.\n\nWe recently fixed one such situation in TCP due to defered freeing of\nskbs (commit 9b6412e6979f (\u0026quot;tcp: drop secpath at the same time as we\ncurrently drop dst\u0026quot;)). This can also happen due to IP reassembly: skbs\nwith a secpath remain on the reassembly queue until netns\ndestruction. If we can\u0026apos;t guarantee that the queues are flushed by the\ntime xfrm_state_fini runs, there may still be references to a (user)\nxfrm_state, preventing the timely deletion of the corresponding\nfallback state.\n\nInstead of chasing each instance of skbs holding a secpath one by one,\nthis patch fixes the issue directly within xfrm, by deleting the\nfallback state as soon as the last user state depending on it has been\ndeleted. Destruction will still happen when the final reference is\ndropped.\n\nA separate lockdep class for the fallback state is required since\nwe\u0026apos;re going to lock x-\u0026gt;tunnel while x is locked.(CVE-2025-40215)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix livelock in synchronous file put from fuseblk workers\n\nI observed a hang when running generic/323 against a fuseblk server.\nThis test opens a file, initiates a lot of AIO writes to that file\ndescriptor, and closes the file descriptor before the writes complete.\nUnsurprisingly, the AIO exerciser threads are mostly stuck waiting for\nresponses from the fuseblk server:\n\n# cat /proc/372265/task/372313/stack\n[\u0026lt;0\u0026gt;] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u0026lt;0\u0026gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_do_getattr+0xfc/0x1f0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_file_read_iter+0xbe/0x1c0 [fuse]\n[\u0026lt;0\u0026gt;] aio_read+0x130/0x1e0\n[\u0026lt;0\u0026gt;] io_submit_one+0x542/0x860\n[\u0026lt;0\u0026gt;] __x64_sys_io_submit+0x98/0x1a0\n[\u0026lt;0\u0026gt;] do_syscall_64+0x37/0xf0\n[\u0026lt;0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nBut the /weird/ part is that the fuseblk server threads are waiting for\nresponses from itself:\n\n# cat /proc/372210/task/372232/stack\n[\u0026lt;0\u0026gt;] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u0026lt;0\u0026gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_file_put+0x9a/0xd0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_release+0x36/0x50 [fuse]\n[\u0026lt;0\u0026gt;] __fput+0xec/0x2b0\n[\u0026lt;0\u0026gt;] task_work_run+0x55/0x90\n[\u0026lt;0\u0026gt;] syscall_exit_to_user_mode+0xe9/0x100\n[\u0026lt;0\u0026gt;] do_syscall_64+0x43/0xf0\n[\u0026lt;0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe fuseblk server is fuse2fs so there\u0026apos;s nothing all that exciting in\nthe server itself. So why is the fuse server calling fuse_file_put?\nThe commit message for the fstest sheds some light on that:\n\n\u0026quot;By closing the file descriptor before calling io_destroy, you pretty\nmuch guarantee that the last put on the ioctx will be done in interrupt\ncontext (during I/O completion).\n\nAha. AIO fgets a new struct file from the fd when it queues the ioctx.\nThe completion of the FUSE_WRITE command from userspace causes the fuse\nserver to call the AIO completion function. The completion puts the\nstruct file, queuing a delayed fput to the fuse server task. When the\nfuse server task returns to userspace, it has to run the delayed fput,\nwhich in the case of a fuseblk server, it does synchronously.\n\nSending the FUSE_RELEASE command sychronously from fuse server threads\nis a bad idea because a client program can initiate enough simultaneous\nAIOs such that all the fuse server threads end up in delayed_fput, and\nnow there aren\u0026apos;t any threads left to handle the queued fuse commands.\n\nFix this by only using asynchronous fputs when closing files, and leave\na comment explaining why.(CVE-2025-40220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/notify: call exportfs_encode_fid with s_umount\n\nCalling intotify_show_fdinfo() on fd watching an overlayfs inode, while\nthe overlayfs is being unmounted, can lead to dereferencing NULL ptr.\n\nThis issue was found by syzkaller.\n\nRace Condition Diagram:\n\nThread 1 Thread 2\n-------- --------\n\ngeneric_shutdown_super()\n shrink_dcache_for_umount\n sb-\u0026gt;s_root = NULL\n\n |\n | vfs_read()\n | inotify_fdinfo()\n | * inode get from mark *\n | show_mark_fhandle(m, inode)\n | exportfs_encode_fid(inode, ..)\n | ovl_encode_fh(inode, ..)\n | ovl_check_encode_origin(inode)\n | * deref i_sb-\u0026gt;s_root *\n |\n |\n v\n fsnotify_sb_delete(sb)\n\nWhich then leads to:\n\n[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)\n\n\u0026lt;snip registers, unreliable trace\u0026gt;\n\n[ 32.143353] Call Trace:\n[ 32.143732] ovl_encode_fh+0xd5/0x170\n[ 32.144031] exportfs_encode_inode_fh+0x12f/0x300\n[ 32.144425] show_mark_fhandle+0xbe/0x1f0\n[ 32.145805] inotify_fdinfo+0x226/0x2d0\n[ 32.146442] inotify_show_fdinfo+0x1c5/0x350\n[ 32.147168] seq_show+0x530/0x6f0\n[ 32.147449] seq_read_iter+0x503/0x12a0\n[ 32.148419] seq_read+0x31f/0x410\n[ 32.150714] vfs_read+0x1f0/0x9e0\n[ 32.152297] ksys_read+0x125/0x240\n\nIOW ovl_check_encode_origin derefs inode-\u0026gt;i_sb-\u0026gt;s_root, after it was set\nto NULL in the unmount path.\n\nFix it by protecting calling exportfs_encode_fid() from\nshow_mark_fhandle() with s_umount lock.\n\nThis form of fix was suggested by Amir in [1].\n\n[1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/(CVE-2025-40237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix unlikely race in gdlm_put_lock\n\nIn gdlm_put_lock(), there is a small window of time in which the\nDFL_UNMOUNT flag has been set but the lockspace hasn\u0026apos;t been released,\nyet. In that window, dlm may still call gdlm_ast() and gdlm_bast().\nTo prevent it from dereferencing freed glock objects, only free the\nglock if the lockspace has actually been released.(CVE-2025-40242)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndevlink: rate: Unset parent pointer in devl_rate_nodes_destroy\n\nThe function devl_rate_nodes_destroy is documented to \u0026quot;Unset parent for\nall rate objects\u0026quot;. However, it was only calling the driver-specific\n`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing\nthe parent\u0026apos;s refcount, without actually setting the\n`devlink_rate-\u0026gt;parent` pointer to NULL.\n\nThis leaves a dangling pointer in the `devlink_rate` struct, which cause\nrefcount error in netdevsim[1] and mlx5[2]. In addition, this is\ninconsistent with the behavior of `devlink_nl_rate_parent_node_set`,\nwhere the parent pointer is correctly cleared.\n\nThis patch fixes the issue by explicitly setting `devlink_rate-\u0026gt;parent`\nto NULL after notifying the driver, thus fulfilling the function\u0026apos;s\ndocumented behavior for all rate objects.\n\n[1]\nrepro steps:\necho 1 \u0026gt; /sys/bus/netdevsim/new_device\ndevlink dev eswitch set netdevsim/netdevsim1 mode switchdev\necho 1 \u0026gt; /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs\ndevlink port function rate add netdevsim/netdevsim1/test_node\ndevlink port function rate set netdevsim/netdevsim1/128 parent test_node\necho 1 \u0026gt; /sys/bus/netdevsim/del_device\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n devl_rate_leaf_destroy+0x8d/0x90\n __nsim_dev_port_del+0x6c/0x70 [netdevsim]\n nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]\n nsim_drv_remove+0x2b/0xb0 [netdevsim]\n device_release_driver_internal+0x194/0x1f0\n bus_remove_device+0xc6/0x130\n device_del+0x159/0x3c0\n device_unregister+0x1a/0x60\n del_device_store+0x111/0x170 [netdevsim]\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x55/0x10f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\ndevlink dev eswitch set pci/0000:08:00.0 mode switchdev\ndevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000\ndevlink port function rate add pci/0000:08:00.0/group1\ndevlink port function rate set pci/0000:08:00.0/32768 parent group1\nmodprobe -r mlx5_ib mlx5_fwctl mlx5_core\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n devl_rate_leaf_destroy+0x8d/0x90\n mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]\n mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]\n mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]\n mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]\n notifier_call_chain+0x33/0xa0\n blocking_notifier_call_chain+0x3b/0x50\n mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]\n mlx5_eswitch_disable+0x63/0x90 [mlx5_core]\n mlx5_unload+0x1d/0x170 [mlx5_core]\n mlx5_uninit_one+0xa2/0x130 [mlx5_core]\n remove_one+0x78/0xd0 [mlx5_core]\n pci_device_remove+0x39/0xa0\n device_release_driver_internal+0x194/0x1f0\n unbind_store+0x99/0xa0\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x53/0x1f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-40251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u0026gt;dev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026amp;proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026amp;proc_subdir_lock);\n [time window] | rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n | write_unlock(\u0026amp;proc_subdir_lock);\n read_lock(\u0026amp;proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)(CVE-2025-40271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/secretmem: fix use-after-free race in fault handler\n\nWhen a page fault occurs in a secret memory file created with\n`memfd_secret(2)`, the kernel will allocate a new folio for it, mark the\nunderlying page as not-present in the direct map, and add it to the file\nmapping.\n\nIf two tasks cause a fault in the same page concurrently, both could end\nup allocating a folio and removing the page from the direct map, but only\none would succeed in adding the folio to the file mapping. The task that\nfailed undoes the effects of its attempt by (a) freeing the folio again\nand (b) putting the page back into the direct map. However, by doing\nthese two operations in this order, the page becomes available to the\nallocator again before it is placed back in the direct mapping.\n\nIf another task attempts to allocate the page between (a) and (b), and the\nkernel tries to access it via the direct map, it would result in a\nsupervisor not-present page fault.\n\nFix the ordering to restore the direct map before the folio is freed.(CVE-2025-40272)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE\n\nThis data originates from userspace and is used in buffer offset\ncalculations which could potentially overflow causing an out-of-bounds\naccess.(CVE-2025-40277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()\n\nIn the parse_adv_monitor_pattern() function, the value of\nthe \u0026apos;length\u0026apos; variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251).\nThe size of the \u0026apos;value\u0026apos; array in the mgmt_adv_pattern structure is 31.\nIf the value of \u0026apos;pattern[i].length\u0026apos; is set in the user space\nand exceeds 31, the \u0026apos;patterns[i].value\u0026apos; array can be accessed\nout of bound when copied.\n\nIncreasing the size of the \u0026apos;value\u0026apos; array in\nthe \u0026apos;mgmt_adv_pattern\u0026apos; structure will break the userspace.\nConsidering this, and to avoid OOB access revert the limits for \u0026apos;offset\u0026apos;\nand \u0026apos;length\u0026apos; back to the value of HCI_MAX_AD_LENGTH.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with SVACE.(CVE-2025-40294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: validate skb length for unknown CC opcode\n\nIn hci_cmd_complete_evt(), if the command complete event has an unknown\nopcode, we assume the first byte of the remaining skb-\u0026gt;data contains the\nreturn status. However, parameter data has previously been pulled in\nhci_event_func(), which may leave the skb empty. If so, using skb-\u0026gt;data[0]\nfor the return status uses un-init memory.\n\nThe fix is to check skb-\u0026gt;len before using skb-\u0026gt;data.(CVE-2025-40301)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bcsp: receive data only if registered\n\nCurrently, bcsp_recv() can be called even when the BCSP protocol has not\nbeen registered. This leads to a NULL pointer dereference, as shown in\nthe following stack trace:\n\n KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]\n RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590\n Call Trace:\n \u0026lt;TASK\u0026gt;\n hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627\n tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290\n tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nTo prevent this, ensure that the HCI_UART_REGISTERED flag is set before\nprocessing received data. If the protocol is not registered, return\n-EUNATCH.(CVE-2025-40308)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once\n\nhci_cmd_sync_dequeue_once() does lookup and then cancel\nthe entry under two separate lock sections. Meanwhile,\nhci_cmd_sync_work() can also delete the same entry,\nleading to double list_del() and \u0026quot;UAF\u0026quot;.\n\nFix this by holding cmd_sync_work_lock across both\nlookup and cancel, so that the entry cannot be removed\nconcurrently.(CVE-2025-40318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Don\u0026apos;t leak robust_list pointer on exec race\n\nsys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()\nto check if the calling task is allowed to access another task\u0026apos;s\nrobust_list pointer. This check is racy against a concurrent exec() in the\ntarget process.\n\nDuring exec(), a task may transition from a non-privileged binary to a\nprivileged one (e.g., setuid binary) and its credentials/memory mappings\nmay change. If get_robust_list() performs ptrace_may_access() before\nthis transition, it may erroneously allow access to sensitive information\nafter the target becomes privileged.\n\nA racy access allows an attacker to exploit a window during which\nptrace_may_access() passes before a target process transitions to a\nprivileged state via exec().\n\nFor example, consider a non-privileged task T that is about to execute a\nsetuid-root binary. An attacker task A calls get_robust_list(T) while T\nis still unprivileged. Since ptrace_may_access() checks permissions\nbased on current credentials, it succeeds. However, if T begins exec\nimmediately afterwards, it becomes privileged and may change its memory\nmappings. Because get_robust_list() proceeds to access T-\u0026gt;robust_list\nwithout synchronizing with exec() it may read user-space pointers from a\nnow-privileged process.\n\nThis violates the intended post-exec access restrictions and could\nexpose sensitive memory addresses or be used as a primitive in a larger\nexploit chain. Consequently, the race can lead to unauthorized\ndisclosure of information across privilege boundaries and poses a\npotential security risk.\n\nTake a read lock on signal-\u0026gt;exec_update_lock prior to invoking\nptrace_may_access() and accessing the robust_list/compat_robust_list.\nThis ensures that the target task\u0026apos;s exec state remains stable during the\ncheck, allowing for consistent and synchronized validation of\ncredentials.(CVE-2025-40341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: use lock accessing port_state and rport state\n\nnvme_fc_unregister_remote removes the remote port on a lport object at\nany point in time when there is no active association. This races with\nwith the reconnect logic, because nvme_fc_create_association is not\ntaking a lock to check the port_state and atomically increase the\nactive count on the rport.(CVE-2025-40342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-fc: avoid scheduling association deletion twice\n\nWhen forcefully shutting down a port via the configfs interface,\nnvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and\nthen nvmet_disable_port(). Both functions will eventually schedule all\nremaining associations for deletion.\n\nThe current implementation checks whether an association is about to be\nremoved, but only after the work item has already been scheduled. As a\nresult, it is possible for the first scheduled work item to free all\nresources, and then for the same work item to be scheduled again for\ndeletion.\n\nBecause the association list is an RCU list, it is not possible to take\na lock and remove the list entry directly, so it cannot be looked up\nagain. Instead, a flag (terminating) must be used to determine whether\nthe association is already in the process of being deleted.(CVE-2025-40343)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Fix incorrect error check in topology_parse_cpu_capacity()\n\nFix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()\nwhich causes the code to proceed with NULL clock pointers. The current\nlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both\nvalid pointers and NULL, leading to potential NULL pointer dereference\nin clk_get_rate().\n\nPer include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:\n\u0026quot;The error code within @ptr if it is an error pointer; 0 otherwise.\u0026quot;\n\nThis means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL\npointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)\nwhen cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be\ncalled when of_clk_get() returns NULL.\n\nReplace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid\npointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()\n\nThe syzbot reported issue in hfsplus_delete_cat():\n\n[ 70.682285][ T9333] =====================================================\n[ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220\n[ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220\n[ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0\n[ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310\n[ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810\n[ 70.685447][ T9333] do_rmdir+0x964/0xea0\n[ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0\n[ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0\n[ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.687646][ T9333]\n[ 70.687856][ T9333] Uninit was stored to memory at:\n[ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0\n[ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800\n[ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600\n[ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70\n[ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0\n[ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30\n[ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0\n[ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0\n[ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.692773][ T9333]\n[ 70.692990][ T9333] Uninit was stored to memory at:\n[ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0\n[ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800\n[ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700\n[ 70.694911][ T9333] mount_bdev+0x37b/0x530\n[ 70.695320][ T9333] hfsplus_mount+0x4d/0x60\n[ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0\n[ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0\n[ 70.696588][ T9333] do_new_mount+0x73e/0x1630\n[ 70.697013][ T9333] path_mount+0x6e3/0x1eb0\n[ 70.697425][ T9333] __se_sys_mount+0x733/0x830\n[ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150\n[ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0\n[ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.699730][ T9333]\n[ 70.699946][ T9333] Uninit was created at:\n[ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60\n[ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0\n[ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0\n[ 70.701774][ T9333] allocate_slab+0x30e/0x1390\n[ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0\n[ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20\n[ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0\n[ 70.703598][ T9333] alloc_inode+0x82/0x490\n[ 70.703984][ T9333] iget_locked+0x22e/0x1320\n[ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0\n[ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0\n[ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700\n[ 70.705776][ T9333] mount_bdev+0x37b/0x530\n[ 70.706171][ T9333] hfsplus_mount+0x4d/0x60\n[ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0\n[ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0\n[ 70.707444][ T9333] do_new_mount+0x73e/0x1630\n[ 70.707865][ T9333] path_mount+0x6e3/0x1eb0\n[ 70.708270][ T9333] __se_sys_mount+0x733/0x830\n[ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150\n[ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0\n[ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.710611][ T9333]\n[ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17\n[ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 70.712490][ T9333] =====================================================\n[ 70.713085][ T9333] Disabling lock debugging due to kernel taint\n[ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...\n[ 70.714159][ T9333] \n---truncated---(CVE-2025-40351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: stacktrace: Disable KASAN checks for non-current tasks\n\nUnwinding the stack of a task other than current, KASAN would report\n\u0026quot;BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460\u0026quot;\n\nThere is a same issue on x86 and has been resolved by the commit\n84936118bdf3 (\u0026quot;x86/unwind: Disable KASAN checks for non-current tasks\u0026quot;)\nThe solution could be applied to RISC-V too.\n\nThis patch also can solve the issue:\nhttps://seclists.org/oss-sec/2025/q4/23\n\n[(CVE-2025-40358)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: Fix KASAN global-out-of-bounds warning\n\nWhen running \u0026quot;perf mem record\u0026quot; command on CWF, the below KASAN\nglobal-out-of-bounds warning is seen.\n\n ==================================================================\n BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0\n Read of size 4 at addr ffffffffb721d000 by task dtlb/9850\n\n Call Trace:\n\n kasan_report+0xb8/0xf0\n cmt_latency_data+0x176/0x1b0\n setup_arch_pebs_sample_data+0xf49/0x2560\n intel_pmu_drain_arch_pebs+0x577/0xb00\n handle_pmi_common+0x6c4/0xc80\n\nThe issue is caused by below code in __grt_latency_data(). The code\ntries to access x86_hybrid_pmu structure which doesn\u0026apos;t exist on\nnon-hybrid platform like CWF.\n\n WARN_ON_ONCE(hybrid_pmu(event-\u0026gt;pmu)-\u0026gt;pmu_type == hybrid_big)\n\nSo add is_hybrid() check before calling this WARN_ON_ONCE to fix the\nglobal-out-of-bounds access issue.(CVE-2025-40359)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-40361)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Ensure XFD state on signal delivery\n\nSean reported [1] the following splat when running KVM tests:\n\n WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70\n Call Trace:\n \u0026lt;TASK\u0026gt;\n fpu__clear_user_states+0x9c/0x100\n arch_do_signal_or_restart+0x142/0x210\n exit_to_user_mode_loop+0x55/0x100\n do_syscall_64+0x205/0x2c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nChao further identified [2] a reproducible scenario involving signal\ndelivery: a non-AMX task is preempted by an AMX-enabled task which\nmodifies the XFD MSR.\n\nWhen the non-AMX task resumes and reloads XSTATE with init values,\na warning is triggered due to a mismatch between fpstate::xfd and the\nCPU\u0026apos;s current XFD state. fpu__clear_user_states() does not currently\nre-synchronize the XFD state after such preemption.\n\nInvoke xfd_update_state() which detects and corrects the mismatch if\nthere is a dynamic feature.\n\nThis also benefits the sigreturn path, as fpu__restore_sig() may call\nfpu__clear_user_states() when the sigframe is inaccessible.\n\n[ dhansen: minor changelog munging ](CVE-2025-68171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix softlockup in ftrace_module_enable\n\nA soft lockup was observed when loading amdgpu module.\nIf a module has a lot of tracable functions, multiple calls\nto kallsyms_lookup can spend too much time in RCU critical\nsection and with disabled preemption, causing kernel panic.\nThis is the same issue that was fixed in\ncommit d0b24b4e91fc (\u0026quot;ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY\nkernels\u0026quot;) and commit 42ea22e754ba (\u0026quot;ftrace: Add cond_resched() to\nftrace_graph_set_hash()\u0026quot;).\n\nFix it the same way by adding cond_resched() in ftrace_module_enable.(CVE-2025-68173)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\namd/amdkfd: enhance kfd process check in switch partition\n\ncurrent switch partition only check if kfd_processes_table is empty.\nkfd_prcesses_table entry is deleted in kfd_process_notifier_release, but\nkfd_process tear down is in kfd_process_wq_release.\n\nconsider two processes:\n\nProcess A (workqueue) -\u0026gt; kfd_process_wq_release -\u0026gt; Access kfd_node member\nProcess B switch partition -\u0026gt; amdgpu_xcp_pre_partition_switch -\u0026gt; amdgpu_amdkfd_device_fini_sw\n-\u0026gt; kfd_node tear down.\n\nProcess A and B may trigger a race as shown in dmesg log.\n\nThis patch is to resolve the race by adding an atomic kfd_process counter\nkfd_processes_count, it increment as create kfd process, decrement as\nfinish kfd_process_wq_release.\n\nv2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds\nand bug fix. (Philip Yang)\n\n[3966658.307702] divide error: 0000 [#1] SMP NOPTI\n[3966658.350818] i10nm_edac\n[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted\n[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]\n[3966658.362839] nfit\n[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu]\n[3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 \u0026lt;f7\u0026gt; be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00\n[3966658.380967] x86_pkg_temp_thermal\n[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246\n[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000\n[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00\n[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4\n[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000\n[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800\n[3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000\n[3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0\n[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[3966658.391536] PKRU: 55555554\n[3966658.391536] Call Trace:\n[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu]\n[3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu]\n[3966658.399754] intel_powerclamp\n[3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu]\n[3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu]\n[3966658.410516] coretemp\n[3966658.434016] process_one_work+0x1ad/0x380\n[3966658.434021] worker_thread+0x49/0x310\n[3966658.438963] kvm_intel\n[3966658.446041] ? process_one_work+0x380/0x380\n[3966658.446045] kthread+0x118/0x140\n[3966658.446047] ? __kthread_bind_mask+0x60/0x60\n[3966658.446050] ret_from_fork+0x1f/0x30\n[3966658.446053] Modules linked in: kpatch_20765354(OEK)\n[3966658.455310] kvm\n[3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)\n[3966658.473462] idxd_mdev\n[3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo\n---truncated---(CVE-2025-68174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: cadence: Check for the existence of cdns_pcie::ops before using it\n\ncdns_pcie::ops might not be populated by all the Cadence glue drivers. This\nis going to be true for the upcoming Sophgo platform which doesn\u0026apos;t set the\nops.\n\nHence, add a check to prevent NULL pointer dereference.\n\n[mani: reworded subject and description](CVE-2025-68176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()\n\nUse RCU to avoid a pair of atomic operations and a potential\nUAF on dst_dev()-\u0026gt;flags.(CVE-2025-68188)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Add bpf_prog_run_data_pointers()\n\nsyzbot found that cls_bpf_classify() is able to change\ntc_skb_cb(skb)-\u0026gt;drop_reason triggering a warning in sk_skb_reason_drop().\n\nWARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]\nWARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214\n\nstruct tc_skb_cb has been added in commit ec624fe740b4 (\u0026quot;net/sched:\nExtend qdisc control block with tc control block\u0026quot;), which added a wrong\ninteraction with db58ba459202 (\u0026quot;bpf: wire in data and data_end for\ncls_act_bpf\u0026quot;).\n\ndrop_reason was added later.\n\nAdd bpf_prog_run_data_pointers() helper to save/restore the net_sched\nstorage colliding with BPF data_meta/data_end.(CVE-2025-68200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: add seqadj extension for natted connections\n\nSequence adjustment may be required for FTP traffic with PASV/EPSV modes.\ndue to need to re-write packet payload (IP, port) on the ftp control\nconnection. This can require changes to the TCP length and expected\nseq / ack_seq.\n\nThe easiest way to reproduce this issue is with PASV mode.\nExample ruleset:\ntable inet ftp_nat {\n ct helper ftp_helper {\n type \u0026quot;ftp\u0026quot; protocol tcp\n l3proto inet\n }\n\n chain prerouting {\n type filter hook prerouting priority 0; policy accept;\n tcp dport 21 ct state new ct helper set \u0026quot;ftp_helper\u0026quot;\n }\n}\ntable ip nat {\n chain prerouting {\n type nat hook prerouting priority -100; policy accept;\n tcp dport 21 dnat ip prefix to ip daddr map {\n\t\t\t192.168.100.1 : 192.168.13.2/32 }\n }\n\n chain postrouting {\n type nat hook postrouting priority 100 ; policy accept;\n tcp sport 21 snat ip prefix to ip saddr map {\n\t\t\t192.168.13.2 : 192.168.100.1/32 }\n }\n}\n\nNote that the ftp helper gets assigned *after* the dnat setup.\n\nThe inverse (nat after helper assign) is handled by an existing\ncheck in nf_nat_setup_info() and will not show the problem.\n\nTopoloy:\n\n +-------------------+ +----------------------------------+\n | FTP: 192.168.13.2 | \u0026lt;-\u0026gt; | NAT: 192.168.13.3, 192.168.100.1 |\n +-------------------+ +----------------------------------+\n |\n +-----------------------+\n | Client: 192.168.100.2 |\n +-----------------------+\n\nftp nat changes do not work as expected in this case:\nConnected to 192.168.100.1.\n[..]\nftp\u0026gt; epsv\nEPSV/EPRT on IPv4 off.\nftp\u0026gt; ls\n227 Entering passive mode (192,168,100,1,209,129).\n421 Service not available, remote server has closed connection.\n\nKernel logs:\nMissing nfct_seqadj_ext_add() setup call\nWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41\n[..]\n __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat]\n nf_nat_ftp+0x142/0x280 [nf_nat_ftp]\n help+0x4d1/0x880 [nf_conntrack_ftp]\n nf_confirm+0x122/0x2e0 [nf_conntrack]\n nf_hook_slow+0x3c/0xb0\n ..\n\nFix this by adding the required extension when a conntrack helper is assigned\nto a connection that has a nat binding.(CVE-2025-68206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: account for current allocated stack depth in widen_imprecise_scalars()\n\nThe usage pattern for widen_imprecise_scalars() looks as follows:\n\n prev_st = find_prev_entry(env, ...);\n queued_st = push_stack(...);\n widen_imprecise_scalars(env, prev_st, queued_st);\n\nWhere prev_st is an ancestor of the queued_st in the explored states\ntree. This ancestor is not guaranteed to have same allocated stack\ndepth as queued_st. E.g. in the following case:\n\n def main():\n for i in 1..2:\n foo(i) // same callsite, differnt param\n\n def foo(i):\n if i == 1:\n use 128 bytes of stack\n iterator based loop\n\nHere, for a second \u0026apos;foo\u0026apos; call prev_st-\u0026gt;allocated_stack is 128,\nwhile queued_st-\u0026gt;allocated_stack is much smaller.\nwiden_imprecise_scalars() needs to take this into account and avoid\naccessing bpf_verifier_state-\u0026gt;frame[*]-\u0026gt;stack out of bounds.(CVE-2025-68208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntimers: Fix NULL function pointer race in timer_shutdown_sync()\n\nThere is a race condition between timer_shutdown_sync() and timer\nexpiration that can lead to hitting a WARN_ON in expire_timers().\n\nThe issue occurs when timer_shutdown_sync() clears the timer function\nto NULL while the timer is still running on another CPU. The race\nscenario looks like this:\n\nCPU0\t\t\t\t\tCPU1\n\t\t\t\t\t\u0026lt;SOFTIRQ\u0026gt;\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tbase-\u0026gt;running_timer = timer;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t[call_timer_fn enter]\n\t\t\t\t\tmod_timer()\n\t\t\t\t\t...\ntimer_shutdown_sync()\nlock_timer_base()\n// For now, will not detach the timer but only clear its function to NULL\nif (base-\u0026gt;running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer-\u0026gt;function = NULL;\nunlock_timer_base()\n\t\t\t\t\t[call_timer_fn exit]\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\tbase-\u0026gt;running_timer = NULL;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t...\n\t\t\t\t\t// Now timer is pending while its function set to NULL.\n\t\t\t\t\t// next timer trigger\n\t\t\t\t\t\u0026lt;SOFTIRQ\u0026gt;\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tWARN_ON_ONCE(!fn) // hit\n\t\t\t\t\t...\nlock_timer_base()\n// Now timer will detach\nif (base-\u0026gt;running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer-\u0026gt;function = NULL;\nunlock_timer_base()\n\nThe problem is that timer_shutdown_sync() clears the timer function\nregardless of whether the timer is currently running. This can leave a\npending timer with a NULL function pointer, which triggers the\nWARN_ON_ONCE(!fn) check in expire_timers().\n\nFix this by only clearing the timer function when actually detaching the\ntimer. If the timer is running, leave the function pointer intact, which is\nsafe because the timer will be properly detached when it finishes running.(CVE-2025-68214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot\n\nnvkm_falcon_fw::boot is allocated, but no one frees it. This causes a\nkmemleak warning.\n\nMake sure this data is deallocated.(CVE-2025-68235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Don\u0026apos;t skip unrelated instruction if INT3/INTO is replaced\n\nWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTn\ninstruction, discard the exception and retry the instruction if the code\nstream is changed (e.g. by a different vCPU) between when the CPU\nexecutes the instruction and when KVM decodes the instruction to get the\nnext RIP.\n\nAs effectively predicted by commit 6ef88d6e36c2 (\u0026quot;KVM: SVM: Re-inject\nINT3/INTO instead of retrying the instruction\u0026quot;), failure to verify that\nthe correct INTn instruction was decoded can effectively clobber guest\nstate due to decoding the wrong instruction and thus specifying the\nwrong next RIP.\n\nThe bug most often manifests as \u0026quot;Oops: int3\u0026quot; panics on static branch\nchecks in Linux guests. Enabling or disabling a static branch in Linux\nuses the kernel\u0026apos;s \u0026quot;text poke\u0026quot; code patching mechanism. To modify code\nwhile other CPUs may be executing that code, Linux (temporarily)\nreplaces the first byte of the original instruction with an int3 (opcode\n0xcc), then patches in the new code stream except for the first byte,\nand finally replaces the int3 with the first byte of the new code\nstream. If a CPU hits the int3, i.e. executes the code while it\u0026apos;s being\nmodified, then the guest kernel must look up the RIP to determine how to\nhandle the #BP, e.g. by emulating the new instruction. If the RIP is\nincorrect, then this lookup fails and the guest kernel panics.\n\nThe bug reproduces almost instantly by hacking the guest kernel to\nrepeatedly check a static branch[1] while running a drgn script[2] on\nthe host to constantly swap out the memory containing the guest\u0026apos;s TSS.\n\n[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a\n[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b(CVE-2025-68259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: add i_data_sem protection in ext4_destroy_inline_data_nolock()\n\nFix a race between inline data destruction and block mapping.\n\nThe function ext4_destroy_inline_data_nolock() changes the inode data\nlayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.\nAt the same time, another thread may execute ext4_map_blocks(), which\ntests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()\nor ext4_ind_map_blocks().\n\nWithout i_data_sem protection, ext4_ind_map_blocks() may receive inode\nwith EXT4_INODE_EXTENTS flag and triggering assert.\n\nkernel BUG at fs/ext4/indirect.c:546!\nEXT4-fs (loop2): unmounting filesystem.\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681\n _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822\n ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124\n ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255\n ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000\n generic_perform_write+0x259/0x5d0 mm/filemap.c:3846\n ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285\n ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679\n call_write_iter include/linux/fs.h:2271 [inline]\n do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735\n do_iter_write+0x186/0x710 fs/read_write.c:861\n vfs_iter_write+0x70/0xa0 fs/read_write.c:902\n iter_file_splice_write+0x73b/0xc90 fs/splice.c:685\n do_splice_from fs/splice.c:763 [inline]\n direct_splice_actor+0x10f/0x170 fs/splice.c:950\n splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896\n do_splice_direct+0x1a9/0x280 fs/splice.c:1002\n do_sendfile+0xb13/0x12c0 fs/read_write.c:1255\n __do_sys_sendfile64 fs/read_write.c:1323 [inline]\n __se_sys_sendfile64 fs/read_write.c:1309 [inline]\n __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2025-68261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: refresh inline data size before write operations\n\nThe cached ei-\u0026gt;i_inline_size can become stale between the initial size\ncheck and when ext4_update_inline_data()/ext4_create_inline_data() use\nit. Although ext4_get_max_inline_size() reads the correct value at the\ntime of the check, concurrent xattr operations can modify i_inline_size\nbefore ext4_write_lock_xattr() is acquired.\n\nThis causes ext4_update_inline_data() and ext4_create_inline_data() to\nwork with stale capacity values, leading to a BUG_ON() crash in\next4_write_inline_data():\n\n kernel BUG at fs/ext4/inline.c:1331!\n BUG_ON(pos + len \u0026gt; EXT4_I(inode)-\u0026gt;i_inline_size);\n\nThe race window:\n1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)\n2. Size check passes for 50-byte write\n3. [Another thread adds xattr, i_inline_size changes to 40]\n4. ext4_write_lock_xattr() acquires lock\n5. ext4_update_inline_data() uses stale i_inline_size = 60\n6. Attempts to write 50 bytes but only 40 bytes actually available\n7. BUG_ON() triggers\n\nFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()\nimmediately after acquiring xattr_sem. This ensures ext4_update_inline_data()\nand ext4_create_inline_data() work with current values that are protected\nfrom concurrent modifications.\n\nThis is similar to commit a54c4613dac1 (\u0026quot;ext4: fix race writing to an\ninline_data file while its xattrs are changing\u0026quot;) which fixed i_inline_off\nstaleness. This patch addresses the related i_inline_size staleness issue.(CVE-2025-68264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix admin request_queue lifetime\n\nThe namespaces can access the controller\u0026apos;s admin request_queue, and\nstale references on the namespaces may exist after tearing down the\ncontroller. Ensure the admin request_queue is active by moving the\ncontroller\u0026apos;s \u0026apos;put\u0026apos; to after all controller references have been released\nto ensure no one is can access the request_queue. This fixes a reported\nuse-after-free bug:\n\n BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0\n Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287\n CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15\n Tainted: [E]=UNSIGNED_MODULE\n Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x4f/0x60\n print_report+0xc4/0x620\n ? _raw_spin_lock_irqsave+0x70/0xb0\n ? _raw_read_unlock_irqrestore+0x30/0x30\n ? blk_queue_enter+0x41c/0x4a0\n kasan_report+0xab/0xe0\n ? blk_queue_enter+0x41c/0x4a0\n blk_queue_enter+0x41c/0x4a0\n ? __irq_work_queue_local+0x75/0x1d0\n ? blk_queue_start_drain+0x70/0x70\n ? irq_work_queue+0x18/0x20\n ? vprintk_emit.part.0+0x1cc/0x350\n ? wake_up_klogd_work_func+0x60/0x60\n blk_mq_alloc_request+0x2b7/0x6b0\n ? __blk_mq_alloc_requests+0x1060/0x1060\n ? __switch_to+0x5b7/0x1060\n nvme_submit_user_cmd+0xa9/0x330\n nvme_user_cmd.isra.0+0x240/0x3f0\n ? force_sigsegv+0xe0/0xe0\n ? nvme_user_cmd64+0x400/0x400\n ? vfs_fileattr_set+0x9b0/0x9b0\n ? cgroup_update_frozen_flag+0x24/0x1c0\n ? cgroup_leave_frozen+0x204/0x330\n ? nvme_ioctl+0x7c/0x2c0\n blkdev_ioctl+0x1a8/0x4d0\n ? blkdev_common_ioctl+0x1930/0x1930\n ? fdget+0x54/0x380\n __x64_sys_ioctl+0x129/0x190\n do_syscall_64+0x5b/0x160\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f765f703b0b\n Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48\n RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b\n RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003\n RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000\n R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003\n R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60\n \u0026lt;/TASK\u0026gt;(CVE-2025-68265)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix crash in process_v2_sparse_read() for encrypted directories\n\nThe crash in process_v2_sparse_read() for fscrypt-encrypted directories\nhas been reported. Issue takes place for Ceph msgr2 protocol in secure\nmode. It can be reproduced by the steps:\n\nsudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure\n\n(1) mkdir /mnt/cephfs/fscrypt-test-3\n(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3\n(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3\n(4) fscrypt lock /mnt/cephfs/fscrypt-test-3\n(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3\n(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar\n(7) Issue has been triggered\n\n[ 408.072247] ------------[ cut here ]------------\n[ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865\nceph_con_v2_try_read+0x4b39/0x72f0\n[ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common\nintel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery\npmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass\npolyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse\nserio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg\npata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore\n[ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+\n[ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.17.0-5.fc42 04/01/2014\n[ 408.072310] Workqueue: ceph-msgr ceph_con_workfn\n[ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0\n[ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8\n8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff \u0026lt;0f\u0026gt; 0b e9 06\nfe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85\n[ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246\n[ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38\n[ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8\n[ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8\n[ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000\n[ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000)\nknlGS:0000000000000000\n[ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0\n[ 408.072336] PKRU: 55555554\n[ 408.072337] Call Trace:\n[ 408.072338] \u0026lt;TASK\u0026gt;\n[ 408.072340] ? sched_clock_noinstr+0x9/0x10\n[ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10\n[ 408.072347] ? _raw_spin_unlock+0xe/0x40\n[ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830\n[ 408.072353] ? __kasan_check_write+0x14/0x30\n[ 408.072357] ? mutex_lock+0x84/0xe0\n[ 408.072359] ? __pfx_mutex_lock+0x10/0x10\n[ 408.072361] ceph_con_workfn+0x27e/0x10e0\n[ 408.072364] ? metric_delayed_work+0x311/0x2c50\n[ 408.072367] process_one_work+0x611/0xe20\n[ 408.072371] ? __kasan_check_write+0x14/0x30\n[ 408.072373] worker_thread+0x7e3/0x1580\n[ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 408.072378] ? __pfx_worker_thread+0x10/0x10\n[ 408.072381] kthread+0x381/0x7a0\n[ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 408.072385] ? __pfx_kthread+0x10/0x10\n[ 408.072387] ? __kasan_check_write+0x14/0x30\n[ 408.072389] ? recalc_sigpending+0x160/0x220\n[ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50\n[ 408.072394] ? calculate_sigpending+0x78/0xb0\n[ 408.072395] ? __pfx_kthread+0x10/0x10\n[ 408.072397] ret_from_fork+0x2b6/0x380\n[ 408.072400] ? __pfx_kthread+0x10/0x10\n[ 408.072402] ret_from_fork_asm+0x1a/0x30\n[ 408.072406] \u0026lt;/TASK\u0026gt;\n[ 408.072407] ---[ end trace 0000000000000000 ]---\n[ 408.072418] Oops: general protection fault, probably for non-canonical\naddress 0xdffffc00000000\n---truncated---(CVE-2025-68297)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI/AER: Fix NULL pointer access by aer_info\n\nThe kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info-\u0026gt;xxx\nwill result in kernel panic. Fix it.(CVE-2025-68309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer\n\nWhen a UAS device is unplugged during data transfer, there is\na probability of a system panic occurring. The root cause is\nan access to an invalid memory address during URB callback handling.\nSpecifically, this happens when the dma_direct_unmap_sg() function\nis called within the usb_hcd_unmap_urb_for_dma() interface, but the\nsg-\u0026gt;dma_address field is 0 and the sg data structure has already been\nfreed.\n\nThe SCSI driver sends transfer commands by invoking uas_queuecommand_lck()\nin uas.c, using the uas_submit_urbs() function to submit requests to USB.\nWithin the uas_submit_urbs() implementation, three URBs (sense_urb,\ndata_urb, and cmd_urb) are sequentially submitted. Device removal may\noccur at any point during uas_submit_urbs execution, which may result\nin URB submission failure. However, some URBs might have been successfully\nsubmitted before the failure, and uas_submit_urbs will return the -ENODEV\nerror code in this case. The current error handling directly calls\nscsi_done(). In the SCSI driver, this eventually triggers scsi_complete()\nto invoke scsi_end_request() for releasing the sgtable. The successfully\nsubmitted URBs, when being unlinked to giveback, call\nusb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg\nunmapping operations since the sg data structure has already been freed.\n\nThis patch modifies the error condition check in the uas_submit_urbs()\nfunction. When a UAS device is removed but one or more URBs have already\nbeen successfully submitted to USB, it avoids immediately invoking\nscsi_done() and save the cmnd to devinfo-\u0026gt;cmnd array. If the successfully\nsubmitted URBs is completed before devinfo-\u0026gt;resetting being set, then\nthe scsi_done() function will be called within uas_try_complete() after\nall pending URB operations are finalized. Otherwise, the scsi_done()\nfunction will be called within uas_zap_pending(), which is executed after\nusb_kill_anchored_urbs().\n\nThe error handling only takes effect when uas_queuecommand_lck() calls\nuas_submit_urbs() and returns the error value -ENODEV . In this case,\nthe device is disconnected, and the flow proceeds to uas_disconnect(),\nwhere uas_zap_pending() is invoked to call uas_try_complete().(CVE-2025-68331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted\n\nThere\u0026apos;s issue when file system corrupted:\n------------[ cut here ]------------\nkernel BUG at fs/jbd2/transaction.c:1289!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next\nRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0\nRSP: 0018:ffff888117aafa30 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534\nRDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010\nRBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028\nR10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __ext4_journal_get_create_access+0x42/0x170\n ext4_getblk+0x319/0x6f0\n ext4_bread+0x11/0x100\n ext4_append+0x1e6/0x4a0\n ext4_init_new_dir+0x145/0x1d0\n ext4_mkdir+0x326/0x920\n vfs_mkdir+0x45c/0x740\n do_mkdirat+0x234/0x2f0\n __x64_sys_mkdir+0xd6/0x120\n do_syscall_64+0x5f/0xfa0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe above issue occurs with us in errors=continue mode when accompanied by\nstorage failures. There have been many inconsistencies in the file system\ndata.\nIn the case of file system data inconsistency, for example, if the block\nbitmap of a referenced block is not set, it can lead to the situation where\na block being committed is allocated and used again. As a result, the\nfollowing condition will not be satisfied then trigger BUG_ON. Of course,\nit is entirely possible to construct a problematic image that can trigger\nthis BUG_ON through specific operations. In fact, I have constructed such\nan image and easily reproduced this issue.\nTherefore, J_ASSERT() holds true only under ideal conditions, but it may\nnot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()\ndirectly in abnormal situations would cause the system to crash, which is\nclearly not what we want. So here we directly trigger a JBD abort instead\nof immediately invoking BUG_ON.(CVE-2025-68337)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid\n\nFixes a crash when layout is null during this call stack:\n\nwrite_inode\n -\u0026gt; nfs4_write_inode\n -\u0026gt; pnfs_layoutcommit_inode\n\npnfs_set_layoutcommit relies on the lseg refcount to keep the layout\naround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt\nto reference a null layout.(CVE-2025-68349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Protect regulator_supply_alias_list with regulator_list_mutex\n\nregulator_supply_alias_list was accessed without any locking in\nregulator_supply_alias(), regulator_register_supply_alias(), and\nregulator_unregister_supply_alias(). Concurrent registration,\nunregistration and lookups can race, leading to:\n\n1 use-after-free if an alias entry is removed while being read,\n2 duplicate entries when two threads register the same alias,\n3 inconsistent alias mappings observed by consumers.\n\nProtect all traversals, insertions and deletions on\nregulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Prevent recursive memory reclaim\n\nFunction new_inode() returns a new inode with inode-\u0026gt;i_mapping-\u0026gt;gfp_mask\nset to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so\nallocations in that address space can recurse into filesystem memory\nreclaim. We don\u0026apos;t want that to happen because it can consume a\nsignificant amount of stack memory.\n\nWorse than that is that it can also deadlock: for example, in several\nplaces, gfs2_unstuff_dinode() is called inside filesystem transactions.\nThis calls filemap_grab_folio(), which can allocate a new folio, which\ncan trigger memory reclaim. If memory reclaim recurses into the\nfilesystem and starts another transaction, a deadlock will ensue.\n\nTo fix these kinds of problems, prevent memory reclaim from recursing\ninto filesystem code by making sure that the gfp_mask of inode address\nspaces doesn\u0026apos;t include __GFP_FS.\n\nThe \u0026quot;meta\u0026quot; and resource group address spaces were already using GFP_NOFS\nas their gfp_mask (which doesn\u0026apos;t include __GFP_FS). The default value\nof GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To\navoid being overly limiting, use the default value and only knock off\nthe __GFP_FS flag. I\u0026apos;m not sure if this will actually make a\ndifference, but it also shouldn\u0026apos;t hurt.\n\nThis patch is loosely based on commit ad22c7a043c2 (\u0026quot;xfs: prevent stack\noverflows from page cache allocation\u0026quot;).\n\nFixes xfstest generic/273.(CVE-2025-68356)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()\n\nThe rtl8187_rx_cb() calculates the rx descriptor header address\nby subtracting its size from the skb tail pointer.\nHowever, it does not validate if the received packet\n(skb-\u0026gt;len from urb-\u0026gt;actual_length) is large enough to contain this\nheader.\n\nIf a truncated packet is received, this will lead to a buffer\nunderflow, reading memory before the start of the skb data area,\nand causing a kernel panic.\n\nAdd length checks for both rtl8187 and rtl8187b descriptor headers\nbefore attempting to access them, dropping the packet cleanly if the\ncheck fails.(CVE-2025-68362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check skb-\u0026gt;transport_header is set in bpf_skb_check_mtu\n\nThe bpf_skb_check_mtu helper needs to use skb-\u0026gt;transport_header when\nthe BPF_MTU_CHK_SEGS flag is used:\n\n\tbpf_skb_check_mtu(skb, ifindex, \u0026amp;mtu_len, 0, BPF_MTU_CHK_SEGS)\n\nThe transport_header is not always set. There is a WARN_ON_ONCE\nreport when CONFIG_DEBUG_NET is enabled + skb-\u0026gt;gso_size is set +\nbpf_prog_test_run is used:\n\nWARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071\n skb_gso_validate_network_len\n bpf_skb_check_mtu\n bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch\n bpf_test_run\n bpf_prog_test_run_skb\n\nFor a normal ingress skb (not test_run), skb_reset_transport_header\nis performed but there is plan to avoid setting it as described in\ncommit 2170a1f09148 (\u0026quot;net: no longer reset transport_header in __netif_receive_skb_core()\u0026quot;).\n\nThis patch fixes the bpf helper by checking\nskb_transport_header_was_set(). The check is done just before\nskb-\u0026gt;transport_header is used, to avoid breaking the existing bpf prog.\nThe WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.(CVE-2025-68363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: ETR: Fix ETR buffer use-after-free issue\n\nWhen ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed\nand enabled again, currently sysfs_buf will point to the newly\nallocated memory(buf_new) and free the old memory(buf_old). But the\netr_buf that is being used by the ETR remains pointed to buf_old, not\nupdated to buf_new. In this case, it will result in a memory\nuse-after-free issue.\n\nFix this by checking ETR\u0026apos;s mode before updating and releasing buf_old,\nif the mode is CS_MODE_SYSFS, then skip updating and releasing it.(CVE-2025-68376)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix stackmap overflow check in __bpf_get_stackid()\n\nSyzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()\nwhen copying stack trace data. The issue occurs when the perf trace\n contains more stack entries than the stack map bucket can hold,\n leading to an out-of-bounds write in the bucket\u0026apos;s data array.(CVE-2025-68378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id\n\nUse check_add_overflow() to guard against potential integer overflows\nwhen adding the binary blob lengths and the size of an asymmetric_key_id\nstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a\npossible buffer overflow when copying data from potentially malicious\nX.509 certificate fields that can be arbitrarily large, such as ASN.1\nINTEGER serial numbers, issuer names, etc.(CVE-2025-68724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Do not let BPF test infra emit invalid GSO types to stack\n\nYinhao et al. reported that their fuzzer tool was able to trigger a\nskb_warn_bad_offload() from netif_skb_features() -\u0026gt; gso_features_check().\nWhen a BPF program - triggered via BPF test infra - pushes the packet\nto the loopback device via bpf_clone_redirect() then mentioned offload\nwarning can be seen. GSO-related features are then rightfully disabled.\n\nWe get into this situation due to convert___skb_to_skb() setting\ngso_segs and gso_size but not gso_type. Technically, it makes sense\nthat this warning triggers since the GSO properties are malformed due\nto the gso_type. Potentially, the gso_type could be marked non-trustworthy\nthrough setting it at least to SKB_GSO_DODGY without any other specific\nassumptions, but that also feels wrong given we should not go further\ninto the GSO engine in the first place.\n\nThe checks were added in 121d57af308d (\u0026quot;gso: validate gso_type in GSO\nhandlers\u0026quot;) because there were malicious (syzbot) senders that combine\na protocol with a non-matching gso_type. If we would want to drop such\npackets, gso_features_check() currently only returns feature flags via\nnetif_skb_features(), so one location for potentially dropping such skbs\ncould be validate_xmit_unreadable_skb(), but then otoh it would be\nan additional check in the fast-path for a very corner case. Given\nbpf_clone_redirect() is the only place where BPF test infra could emit\nsuch packets, lets reject them right there.(CVE-2025-68725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()\n\nIn hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when\nsetup_instance() fails with an error code. Fix that by freeing the urb\nbefore freeing the hw structure. Also change the error paths to use the\ngoto ladder style.\n\nCompile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix improper freeing of purex item\n\nIn qla2xxx_process_purls_iocb(), an item is allocated via\nqla27xx_copy_multiple_pkt(), which internally calls\nqla24xx_alloc_purex_item().\n\nThe qla24xx_alloc_purex_item() function may return a pre-allocated item\nfrom a per-adapter pool for small allocations, instead of dynamically\nallocating memory with kzalloc().\n\nAn error handling path in qla2xxx_process_purls_iocb() incorrectly uses\nkfree() to release the item. If the item was from the pre-allocated\npool, calling kfree() on it is a bug that can lead to memory corruption.\n\nFix this by using the correct deallocation function,\nqla24xx_free_purex_item(), which properly handles both dynamically\nallocated and pre-allocated items.(CVE-2025-68741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Free special fields when update [lru_,]percpu_hash maps\n\nAs [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing\ncalls to \u0026apos;bpf_obj_free_fields()\u0026apos; in \u0026apos;pcpu_copy_value()\u0026apos; could cause the\nmemory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the\nmap gets freed.\n\nFix this by calling \u0026apos;bpf_obj_free_fields()\u0026apos; after\n\u0026apos;copy_map_value[,_long]()\u0026apos; in \u0026apos;pcpu_copy_value()\u0026apos;.(CVE-2025-68744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Clear cmds after chip reset\n\nCommit aefed3e5548f (\u0026quot;scsi: qla2xxx: target: Fix offline port handling\nand host reset handling\u0026quot;) caused two problems:\n\n1. Commands sent to FW, after chip reset got stuck and never freed as FW\n is not going to respond to them anymore.\n\n2. BUG_ON(cmd-\u0026gt;sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a\n (\u0026quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands\u0026quot;)\n attempted to fix this, but introduced another bug under different\n circumstances when two different CPUs were racing to call\n qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in\n dma_unmap_sg_attrs().\n\nSo revert \u0026quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands\u0026quot; and\npartially revert \u0026quot;scsi: qla2xxx: target: Fix offline port handling and\nhost reset handling\u0026quot; at __qla2x00_abort_all_cmds.(CVE-2025-68745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: Use RCU in blk_mq_[un]quiesce_tagset() instead of set-\u0026gt;tag_list_lock\n\nblk_mq_{add,del}_queue_tag_set() functions add and remove queues from\ntagset, the functions make sure that tagset and queues are marked as\nshared when two or more queues are attached to the same tagset.\nInitially a tagset starts as unshared and when the number of added\nqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared along\nwith all the queues attached to it. When the number of attached queues\ndrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and\nthe remaining queues as unshared.\n\nBoth functions need to freeze current queues in tagset before setting on\nunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions\nhold set-\u0026gt;tag_list_lock mutex, which makes sense as we do not want\nqueues to be added or deleted in the process. This used to work fine\nuntil commit 98d81f0df70c (\u0026quot;nvme: use blk_mq_[un]quiesce_tagset\u0026quot;)\nmade the nvme driver quiesce tagset instead of quiscing individual\nqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues in\nset-\u0026gt;tag_list while holding set-\u0026gt;tag_list_lock also.\n\nThis results in deadlock between two threads with these stacktraces:\n\n __schedule+0x47c/0xbb0\n ? timerqueue_add+0x66/0xb0\n schedule+0x1c/0xa0\n schedule_preempt_disabled+0xa/0x10\n __mutex_lock.constprop.0+0x271/0x600\n blk_mq_quiesce_tagset+0x25/0xc0\n nvme_dev_disable+0x9c/0x250\n nvme_timeout+0x1fc/0x520\n blk_mq_handle_expired+0x5c/0x90\n bt_iter+0x7e/0x90\n blk_mq_queue_tag_busy_iter+0x27e/0x550\n ? __blk_mq_complete_request_remote+0x10/0x10\n ? __blk_mq_complete_request_remote+0x10/0x10\n ? __call_rcu_common.constprop.0+0x1c0/0x210\n blk_mq_timeout_work+0x12d/0x170\n process_one_work+0x12e/0x2d0\n worker_thread+0x288/0x3a0\n ? rescuer_thread+0x480/0x480\n kthread+0xb8/0xe0\n ? kthread_park+0x80/0x80\n ret_from_fork+0x2d/0x50\n ? kthread_park+0x80/0x80\n ret_from_fork_asm+0x11/0x20\n\n __schedule+0x47c/0xbb0\n ? xas_find+0x161/0x1a0\n schedule+0x1c/0xa0\n blk_mq_freeze_queue_wait+0x3d/0x70\n ? destroy_sched_domains_rcu+0x30/0x30\n blk_mq_update_tag_set_shared+0x44/0x80\n blk_mq_exit_queue+0x141/0x150\n del_gendisk+0x25a/0x2d0\n nvme_ns_remove+0xc9/0x170\n nvme_remove_namespaces+0xc7/0x100\n nvme_remove+0x62/0x150\n pci_device_remove+0x23/0x60\n device_release_driver_internal+0x159/0x200\n unbind_store+0x99/0xa0\n kernfs_fop_write_iter+0x112/0x1e0\n vfs_write+0x2b1/0x3d0\n ksys_write+0x4e/0xb0\n do_syscall_64+0x5b/0x160\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe top stacktrace is showing nvme_timeout() called to handle nvme\ncommand timeout. timeout handler is trying to disable the controller and\nas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not\nto call queue callback handlers. The thread is stuck waiting for\nset-\u0026gt;tag_list_lock as it tries to walk the queues in set-\u0026gt;tag_list.\n\nThe lock is held by the second thread in the bottom stack which is\nwaiting for one of queues to be frozen. The queue usage counter will\ndrop to zero after nvme_timeout() finishes, and this will not happen\nbecause the thread will wait for this mutex forever.\n\nGiven that [un]quiescing queue is an operation that does not need to\nsleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking\nset-\u0026gt;tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU\nsafe list operations. Also, delete INIT_LIST_HEAD(\u0026amp;q-\u0026gt;tag_set_list)\nin blk_mq_del_queue_tag_set() because we can not re-initialize it while\nthe list is being traversed under RCU. The deleted queue will not be\nadded/deleted to/from a tagset and it will be freed in blk_free_queue()\nafter the end of RCU grace period.(CVE-2025-68756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: only set free_cpus for online runqueues\n\nCommit 16b269436b72 (\u0026quot;sched/deadline: Modify cpudl::free_cpus\nto reflect rd-\u0026gt;online\u0026quot;) introduced the cpudl_set/clear_freecpu\nfunctions to allow the cpu_dl::free_cpus mask to be manipulated\nby the deadline scheduler class rq_on/offline callbacks so the\nmask would also reflect this state.\n\nCommit 9659e1eeee28 (\u0026quot;sched/deadline: Remove cpu_active_mask\nfrom cpudl_find()\u0026quot;) removed the check of the cpu_active_mask to\nsave some processing on the premise that the cpudl::free_cpus\nmask already reflected the runqueue online state.\n\nUnfortunately, there are cases where it is possible for the\ncpudl_clear function to set the free_cpus bit for a CPU when the\ndeadline runqueue is offline. When this occurs while a CPU is\nconnected to the default root domain the flag may retain the bad\nstate after the CPU has been unplugged. Later, a different CPU\nthat is transitioning through the default root domain may push a\ndeadline task to the powered down CPU when cpudl_find sees its\nfree_cpus bit is set. If this happens the task will not have the\nopportunity to run.\n\nOne example is outlined here:\nhttps://lore.kernel.org/lkml/(CVE-2025-68780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Reset t_task_cdb pointer in error case\n\nIf allocation of cmd-\u0026gt;t_task_cdb fails, it remains NULL but is later\ndereferenced in the \u0026apos;err\u0026apos; path.\n\nIn case of error, reset NULL t_task_cdb value to point at the default\nfixed-size buffer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niomap: adjust read range correctly for non-block-aligned positions\n\niomap_adjust_read_range() assumes that the position and length passed in\nare block-aligned. This is not always the case however, as shown in the\nsyzbot generated case for erofs. This causes too many bytes to be\nskipped for uptodate blocks, which results in returning the incorrect\nposition and length to read in. If all the blocks are uptodate, this\nunderflows length and returns a position beyond the folio.\n\nFix the calculation to also take into account the block offset when\ncalculating how many bytes can be skipped for uptodate blocks.(CVE-2025-68794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: NFSv4 file creation neglects setting ACL\n\nAn NFSv4 client that sets an ACL with a named principal during file\ncreation retrieves the ACL afterwards, and finds that it is only a\ndefault ACL (based on the mode bits) and not the ACL that was\nrequested during file creation. This violates RFC 8881 section\n6.4.1.3: \u0026quot;the ACL attribute is set as given\u0026quot;.\n\nThe issue occurs in nfsd_create_setattr(), which calls\nnfsd_attrs_valid() to determine whether to call nfsd_setattr().\nHowever, nfsd_attrs_valid() checks only for iattr changes and\nsecurity labels, but not POSIX ACLs. When only an ACL is present,\nthe function returns false, nfsd_setattr() is skipped, and the\nPOSIX ACL is never applied to the inode.\n\nSubsequently, when the client retrieves the ACL, the server finds\nno POSIX ACL on the inode and returns one generated from the file\u0026apos;s\nmode bits rather than returning the originally-specified ACL.(CVE-2025-68803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix filename leak in __io_openat_prep()\n\n __io_openat_prep() allocates a struct filename using getname(). However,\nfor the condition of the file being installed in the fixed file table as\nwell as having O_CLOEXEC flag set, the function returns early. At that\npoint, the request doesn\u0026apos;t have REQ_F_NEED_CLEANUP flag set. Due to this,\nthe memory for the newly allocated struct filename is not cleaned up,\ncausing a memory leak.\n\nFix this by setting the REQ_F_NEED_CLEANUP for the request just after the\nsuccessful getname() call, so that when the request is torn down, the\nfilename will be cleaned up, along with other resources needing cleanup.(CVE-2025-68814)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: fw_tracer, Validate format string parameters\n\nAdd validation for format string parameters in the firmware tracer to\nprevent potential security vulnerabilities and crashes from malformed\nformat strings received from firmware.\n\nThe firmware tracer receives format strings from the device firmware and\nuses them to format trace messages. Without proper validation, bad\nfirmware could provide format strings with invalid format specifiers\n(e.g., %s, %p, %n) that could lead to crashes, or other undefined\nbehavior.\n\nAdd mlx5_tracer_validate_params() to validate that all format specifiers\nin trace strings are limited to safe integer/hex formats (%x, %d, %i,\n%u, %llx, %lx, etc.). Reject strings containing other format types that\ncould be used to access arbitrary memory or cause crashes.\nInvalid format strings are added to the trace output for visibility with\n\u0026quot;BAD_FORMAT: \u0026quot; prefix.(CVE-2025-68816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \u0026quot;scsi: qla2xxx: Perform lockless command completion in abort path\u0026quot;\n\nThis reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.\n\nThe commit being reverted added code to __qla2x00_abort_all_cmds() to\ncall sp-\u0026gt;done() without holding a spinlock. But unlike the older code\nbelow it, this new code failed to check sp-\u0026gt;cmd_type and just assumed\nTYPE_SRB, which results in a jump to an invalid pointer in target-mode\nwith TYPE_TGT_CMD:\n\nqla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success\n 0000000009f7a79b\nqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h\n mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.\nqla2xxx [0000:65:00.0]-d01e:8: -\u0026gt; fwdump no buffer\nqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event\n 0x8002 occurred\nqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -\n ha=0000000058183fda.\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPF: supervisor instruction fetch in kernel mode\nPF: error_code(0x0010) - not-present page\nPGD 0 P4D 0\nOops: 0010 [#1] SMP\nCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1\nHardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206\nRAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000\nRDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0\nRBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045\nR10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40\nR13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400\nFS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x4d/0x8b\n ? page_fault_oops+0x91/0x180\n ? trace_buffer_unlock_commit_regs+0x38/0x1a0\n ? exc_page_fault+0x391/0x5e0\n ? asm_exc_page_fault+0x22/0x30\n __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]\n qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]\n qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]\n qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]\n qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]\n kthread+0xa8/0xd0\n \u0026lt;/TASK\u0026gt;\n\nThen commit 4475afa2646d (\u0026quot;scsi: qla2xxx: Complete command early within\nlock\u0026quot;) added the spinlock back, because not having the lock caused a\nrace and a crash. But qla2x00_abort_srb() in the switch below already\nchecks for qla2x00_chip_is_down() and handles it the same way, so the\ncode above the switch is now redundant and still buggy in target-mode.\nRemove it.(CVE-2025-68818)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nshmem: fix recovery on rename failures\n\nmaple_tree insertions can fail if we are seriously short on memory;\nsimple_offset_rename() does not recover well if it runs into that.\nThe same goes for simple_offset_rename_exchange().\n\nMoreover, shmem_whiteout() expects that if it succeeds, the caller will\nprogress to d_move(), i.e. that shmem_rename2() won\u0026apos;t fail past the\nsuccessful call of shmem_whiteout().\n\nNot hard to fix, fortunately - mtree_store() can\u0026apos;t fail if the index we\nare trying to store into is already present in the tree as a singleton.\n\nFor simple_offset_rename_exchange() that\u0026apos;s enough - we just need to be\ncareful about the order of operations.\n\nFor simple_offset_rename() solution is to preinsert the target into the\ntree for new_dir; the rest can be done without any potentially failing\noperations.\n\nThat preinsertion has to be done in shmem_rename2() rather than in\nsimple_offset_rename() itself - otherwise we\u0026apos;d need to deal with the\npossibility of failure after successful shmem_whiteout().(CVE-2025-71072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest\u0026apos;s APIC timer in periodic\nmode, set the expiration to \u0026quot;now\u0026quot; if the target expiration is in the past\n(similar to what is done in update_target_expiration()). Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over. In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active. As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past. As a result, the delta\nmay be calculated as a negative value. When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming. I.e. the large\nvalue will exceed the VMX Preemption Timer\u0026apos;s maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM\u0026apos;s request for an expiration in the past and\nimmediately re-invokes KVM\u0026apos;s callback after reprogramming. And because\nthe interrupt handler runs with IRQs disabled, restarting KVM\u0026apos;s hrtimer\nover and over until the target expiration is advanced to \u0026quot;now\u0026quot; can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n ...\n RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n ...\n RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n PKRU: 55555554\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n apic_timer_fn+0x31/0x50 [kvm]\n __hrtimer_run_queues+0x100/0x280\n hrtimer_interrupt+0x100/0x210\n ? ttwu_do_wakeup+0x19/0x160\n smp_apic_timer_interrupt+0x6a/0x130\n apic_timer_interrupt+0xf/0x20\n \u0026lt;/IRQ\u0026gt;\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\u0026quot;KVM: VMX: Move preemption timer \u0026lt;=\u0026gt; hrtimer dance to common x86\u0026quot;), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way. Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---(CVE-2025-71104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: make decode_pool() more resilient against corrupted osdmaps\n\nIf the osdmap is (maliciously) corrupted such that the encoded length\nof ceph_pg_pool envelope is less than what is expected for a particular\nencoding version, out-of-bounds reads may ensue because the only bounds\ncheck that is there is based on that length value.\n\nThis patch adds explicit bounds checks for each field that is decoded\nor skipped.(CVE-2025-71116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: seqiv - Do not use req-\u0026gt;iv after crypto_aead_encrypt\n\nAs soon as crypto_aead_encrypt is called, the underlying request\nmay be freed by an asynchronous completion. Thus dereferencing\nreq-\u0026gt;iv after it returns is invalid.\n\nInstead of checking req-\u0026gt;iv against info, create a new variable\nunaligned_info and use it for that purpose instead.(CVE-2025-71131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Fix a memory leak in tpm2_load_cmd\n\n\u0026apos;tpm2_load_cmd\u0026apos; allocates a tempoary blob indirectly via \u0026apos;tpm2_key_decode\u0026apos;\nbut it is not freed in the failure paths. Address this by wrapping the blob\ninto with a cleanup helper.(CVE-2025-71147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/poll: correctly handle io_poll_add() return value on update\n\nWhen the core of io_uring was updated to handle completions\nconsistently and with fixed return codes, the POLL_REMOVE opcode\nwith updates got slightly broken. If a POLL_ADD is pending and\nthen POLL_REMOVE is used to update the events of that request, if that\nupdate causes the POLL_ADD to now trigger, then that completion is lost\nand a CQE is never posted.\n\nAdditionally, ensure that if an update does cause an existing POLL_ADD\nto complete, that the completion value isn\u0026apos;t always overwritten with\n-ECANCELED. For that case, whatever io_poll_add() set the value to\nshould just be retained.(CVE-2025-71149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix refcount leak when invalid session is found on session lookup\n\nWhen a session is found but its state is not SMB2_SESSION_VALID, It\nindicates that no valid session was found, but it is missing to decrement\nthe reference count acquired by the session lookup, which results in\na reference count leak. This patch fixes the issue by explicitly calling\nksmbd_user_session_put to release the reference to the session.(CVE-2025-71150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Don\u0026apos;t store mlx5e_priv in mlx5e_dev devlink priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails, mlx5e_priv in mlx5e_dev devlink private is used to\nreference the netdev and mdev associated with that struct. Instead,\nstore netdev directly into mlx5e_dev and get mdev from the containing\nmlx5_adev aux device structure.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==\u0026gt; oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000520\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_remove+0x68/0x130\nRSP: 0018:ffffc900034838f0 EFLAGS: 00010246\nRAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\nRBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10\nR10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0\nR13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400\nFS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-22996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\u0026quot;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\u0026quot;)\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command\u0026apos;s data structures (cmd-\u0026gt;req.sg and cmd-\u0026gt;iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT \u2192 both pointers NULL\n2. H2C_DATA PDU for READ command \u2192 cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n3. H2C_DATA PDU for uninitialized command slot \u2192 both pointers NULL\n\nThe fix validates both cmd-\u0026gt;req.sg and cmd-\u0026gt;iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n- WRITE commands: both allocated(CVE-2026-22998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash on profile change rollback failure\n\nmlx5e_netdev_change_profile can fail to attach a new profile and can\nfail to rollback to old profile, in such case, we could end up with a\ndangling netdev with a fully reset netdev_priv. A retry to change\nprofile, e.g. another attempt to call mlx5e_netdev_change_profile via\nswitchdev mode change, will crash trying to access the now NULL\npriv-\u0026gt;mdev.\n\nThis fix allows mlx5e_netdev_change_profile() to handle previous\nfailures and an empty priv, by not assuming priv is valid.\n\nPass netdev and mdev to all flows requiring\nmlx5e_netdev_change_profile() and avoid passing priv.\nIn mlx5e_netdev_change_profile() check if current priv is valid, and if\nnot, just attach the new profile without trying to access the old one.\n\nThis fixes the following oops, when enabling switchdev mode for the 2nd\ntime after first time failure:\n\n ## Enabling switchdev mode first time:\n\nmlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n ^^^^^^^^\nmlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\n\n ## retry: Enabling switchdev mode 2nd time:\n\nmlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload\nBUG: kernel NULL pointer dereference, address: 0000000000000038\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_detach_netdev+0x3c/0x90\nCode: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 \u0026lt;48\u0026gt; 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07\nRSP: 0018:ffffc90000673890 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000\nRDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000\nR10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000\nR13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000\nFS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_netdev_change_profile+0x45/0xb0\n mlx5e_vport_rep_load+0x27b/0x2d0\n mlx5_esw_offloads_rep_load+0x72/0xf0\n esw_offloads_enable+0x5d0/0x970\n mlx5_eswitch_enable_locked+0x349/0x430\n ? is_mp_supported+0x57/0xb0\n mlx5_devlink_eswitch_mode_set+0x26b/0x430\n devlink_nl_eswitch_set_doit+0x6f/0xf0\n genl_family_rcv_msg_doit+0xe8/0x140\n genl_rcv_msg+0x18b/0x290\n ? __pfx_devlink_nl_pre_doit+0x10/0x10\n ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10\n ? __pfx_devlink_nl_post_doit+0x10/0x10\n ? __pfx_genl_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x52/0x100\n genl_rcv+0x28/0x40\n netlink_unicast+0x282/0x3e0\n ? __alloc_skb+0xd6/0x190\n netlink_sendmsg+0x1f7/0x430\n __sys_sendto+0x213/0x220\n ? __sys_recvmsg+0x6a/0xd0\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fdfb8495047(CVE-2026-23000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1\n\nWhen loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in\nresponse to a guest WRMSR, clear XFD-disabled features in the saved (or to\nbe restored) XSTATE_BV to ensure KVM doesn\u0026apos;t attempt to load state for\nfeatures that are disabled via the guest\u0026apos;s XFD. Because the kernel\nexecutes XRSTOR with the guest\u0026apos;s XFD, saving XSTATE_BV[i]=1 with XFD[i]=1\nwill cause XRSTOR to #NM and panic the kernel.\n\nE.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:\n\n ------------[ cut here ]------------\n WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:exc_device_not_available+0x101/0x110\n Call Trace:\n \u0026lt;TASK\u0026gt;\n asm_exc_device_not_available+0x1a/0x20\n RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n switch_fpu_return+0x4a/0xb0\n kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]\n kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n __x64_sys_ioctl+0x8f/0xd0\n do_syscall_64+0x62/0x940\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nThis can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,\nand a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler\u0026apos;s\ncall to fpu_update_guest_xfd().\n\nand if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:\n\n ------------[ cut here ]------------\n WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:exc_device_not_available+0x101/0x110\n Call Trace:\n \u0026lt;TASK\u0026gt;\n asm_exc_device_not_available+0x1a/0x20\n RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n fpu_swap_kvm_fpstate+0x6b/0x120\n kvm_load_guest_fpu+0x30/0x80 [kvm]\n kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]\n kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n __x64_sys_ioctl+0x8f/0xd0\n do_syscall_64+0x62/0x940\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nThe new behavior is consistent with the AMX architecture. Per Intel\u0026apos;s SDM,\nXSAVE saves XSTATE_BV as \u0026apos;0\u0026apos; for components that are disabled via XFD\n(and non-compacted XSAVE saves the initial configuration of the state\ncomponent):\n\n If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,\n the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;\n instead, it operates as if XINUSE[i] = 0 (and the state component was\n in its initial state): it saves bit i of XSTATE_BV field of the XSAVE\n header as 0; in addition, XSAVE saves the initial configuration of the\n state component (the other instructions do not save state component i).\n\nAlternatively, KVM could always do XRSTOR with XFD=0, e.g. by using\na constant XFD based on the set of enabled features when XSAVEing for\na struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled\nfeatures can only happen in the above interrupt case, or in similar\nscenarios involving preemption on preemptible kernels, because\nfpu_swap_kvm_fpstate()\u0026apos;s call to save_fpregs_to_fpstate() saves the\noutgoing FPU state with the current XFD; and that is (on all but the\nfirst WRMSR to XFD) the guest XFD.\n\nTherefore, XFD can only go out of sync with XSTATE_BV in the above\ninterrupt case, or in similar scenarios involving preemption on\npreemptible kernels, and it we can consider it (de facto) part of KVM\nABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.\n\n[Move clea\n---truncated---(CVE-2026-23005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails.\n\nPass netdev to mlx5e_destroy_netdev() to guarantee it will work on a\nvalid netdev.\n\nOn mlx5e_remove: Check validity of priv-\u0026gt;profile, before attempting\nto cleanup any resources that might be not there.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==\u0026gt; oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000370\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100\nRSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286\nRAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0\nRBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10\nR10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0\nR13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400\nFS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_remove+0x57/0x110\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-23035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add recursion protection in kernel stack trace recording\n\nA bug was reported about an infinite recursion caused by tracing the rcu\nevents with the kernel stack trace trigger enabled. The stack trace code\ncalled back into RCU which then called the stack trace again.\n\nExpand the ftrace recursion protection to add a set of bits to protect\nevents from recursion. Each bit represents the context that the event is\nin (normal, softirq, interrupt and NMI).\n\nHave the stack trace code use the interrupt context to protect against\nrecursion.\n\nNote, the bug showed an issue in both the RCU code as well as the tracing\nstacktrace code. This only handles the tracing stack trace side of the\nbug. The RCU fix will be handled separately.(CVE-2026-23138)",
"id": "OESA-2026-1759",
"modified": "2026-08-06T11:10:47Z",
"published": "2026-03-27T11:10:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38373"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38659"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40030"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40215"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40220"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40242"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40251"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40272"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40277"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40294"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40308"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40318"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40341"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40343"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40346"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40351"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40358"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40359"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40361"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68173"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68174"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68188"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68200"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68206"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68208"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68235"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68264"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68297"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68331"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68337"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68349"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68354"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68362"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68363"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68376"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71116"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71147"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23138"
}
],
"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-2024-53232",
"CVE-2025-37900",
"CVE-2025-37954",
"CVE-2025-38083",
"CVE-2025-38373",
"CVE-2025-38556",
"CVE-2025-38591",
"CVE-2025-38659",
"CVE-2025-38730",
"CVE-2025-39713",
"CVE-2025-39961",
"CVE-2025-40030",
"CVE-2025-40096",
"CVE-2025-40215",
"CVE-2025-40220",
"CVE-2025-40237",
"CVE-2025-40242",
"CVE-2025-40251",
"CVE-2025-40271",
"CVE-2025-40272",
"CVE-2025-40277",
"CVE-2025-40294",
"CVE-2025-40301",
"CVE-2025-40308",
"CVE-2025-40318",
"CVE-2025-40341",
"CVE-2025-40342",
"CVE-2025-40343",
"CVE-2025-40346",
"CVE-2025-40351",
"CVE-2025-40358",
"CVE-2025-40359",
"CVE-2025-40361",
"CVE-2025-68171",
"CVE-2025-68173",
"CVE-2025-68174",
"CVE-2025-68176",
"CVE-2025-68188",
"CVE-2025-68200",
"CVE-2025-68206",
"CVE-2025-68208",
"CVE-2025-68214",
"CVE-2025-68235",
"CVE-2025-68259",
"CVE-2025-68261",
"CVE-2025-68264",
"CVE-2025-68265",
"CVE-2025-68297",
"CVE-2025-68309",
"CVE-2025-68331",
"CVE-2025-68337",
"CVE-2025-68349",
"CVE-2025-68354",
"CVE-2025-68356",
"CVE-2025-68362",
"CVE-2025-68363",
"CVE-2025-68376",
"CVE-2025-68378",
"CVE-2025-68724",
"CVE-2025-68725",
"CVE-2025-68734",
"CVE-2025-68741",
"CVE-2025-68744",
"CVE-2025-68745",
"CVE-2025-68756",
"CVE-2025-68780",
"CVE-2025-68782",
"CVE-2025-68794",
"CVE-2025-68803",
"CVE-2025-68814",
"CVE-2025-68816",
"CVE-2025-68818",
"CVE-2025-71072",
"CVE-2025-71104",
"CVE-2025-71116",
"CVE-2025-71131",
"CVE-2025-71147",
"CVE-2025-71149",
"CVE-2025-71150",
"CVE-2026-22996",
"CVE-2026-22998",
"CVE-2026-23000",
"CVE-2026-23005",
"CVE-2026-23035",
"CVE-2026-23138"
]
}
OESA-2026-1760 (CVE-2024-53232)
Vulnerability from osv_openeuler – Published: 2026-03-27 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Implement blocking domain
This fixes a crash when surprise hot-unplugging a PCI device. This crash happens because during hot-unplug __iommu_group_set_domain_nofail() attaching the default domain fails when the platform no longer recognizes the device as it has already been removed and we end up with a NULL domain pointer and UAF. This is exactly the case referred to in the second comment in __iommu_device_set_domain() and just as stated there if we can instead attach the blocking domain the UAF is prevented as this can handle the already removed device. Implement the blocking domain to use this handling. With this change, the crash is fixed but we still hit a warning attempting to change DMA ownership on a blocked device.(CVE-2024-53232)
In the Linux kernel, the following vulnerability has been resolved:
iommu: Fix two issues in iommu_copy_struct_from_user()
In the review for iommu_copy_struct_to_user() helper, Matt pointed out that a NULL pointer should be rejected prior to dereferencing it: https://lore.kernel.org/all/(CVE-2025-37900)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Avoid race in open_cached_dir with lease breaks
A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs.
Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked.(CVE-2025-37954)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: prio: fix a race in prio_tune()
Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 1: lock root
[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.(CVE-2025-38083)
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix potential deadlock in MR deregistration
The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock.
The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | → revoke_mr() | → mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | → mutex_lock(&dev->cache.rb_lock) | → mlx5r_cache_create_ent_locked() | → kzalloc(GFP_KERNEL) | → fs_reclaim() | → mmu_notifier_invalidate_range_start() | → mlx5_ib_invalidate_range() | → mutex_lock(&umem_odp->umem_mutex) → cache_ent_find_and_store() | → mutex_lock(&dev->cache.rb_lock) |
Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex.
Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path.
This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path.
The following lockdep warning demonstrates the deadlock:
python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]
but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138
-> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
-> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core]
---truncated---(CVE-2025-38373)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Harden s32ton() against conversion to 0 bits
Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that.
Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.(CVE-2025-38556)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject narrower access to pointer ctx fields
The following BPF program, simplified from a syzkaller repro, causes a kernel warning:
r0 = *(u8 *)(r1 + 169);
exit;
With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the "is_narrower_load" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning:
verifier bug: error during ctx access conversion(1)
This patch fixes that to return a proper "invalid bpf_context access off=X size=Y" error on the load instruction.
The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency.
Note this syzkaller crash was reported in the "Closes" link below, which used to be about a different bug, fixed in commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.(CVE-2025-38591)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: No more self recovery
When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw.
However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 ("gfs2: Prevent double iput for journal on error") and is a NULL pointer dereference since then.
Simply get rid of self recovery to fix that.(CVE-2025-38659)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/net: commit partial buffers on retry
Ring provided buffers are potentially only valid within the single execution context in which they were acquired. io_uring deals with this and invalidates them on retry. But on the networking side, if MSG_WAITALL is set, or if the socket is of the streaming type and too little was processed, then it will hang on to the buffer rather than recycle or commit it. This is problematic for two reasons:
1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid.
2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer.
Fix this by disallowing partial retries from pinning a provided buffer across multiple executions, if ring provided buffers are used.(CVE-2025-38730)
In the Linux kernel, the following vulnerability has been resolved:
media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()
In the interrupt handler rain_interrupt(), the buffer full check on rain->buf_len is performed before acquiring rain->buf_lock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buf_len is concurrently accessed and modified in the work handler rain_irq_work_handler() under the same lock.
Multiple interrupt invocations can race, with each reading buf_len before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buf_len beyond its capacity (DATA_SIZE) and causing a buffer overflow.
Fix this bug by moving the spin_lock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spin_unlock() is added to the overflow path to correctly release the lock.
This possible bug was found by an experimental static analysis tool developed by our team.(CVE-2025-39713)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd/pgtbl: Fix possible race while increase page table level
The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations.
The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level.
But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON.
CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)
Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.(CVE-2025-39961)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: check the return value of pinmux_ops::get_function_name()
While the API contract in docs doesn't specify it explicitly, the generic implementation of the get_function_name() callback from struct pinmux_ops - pinmux_generic_get_function_name() - can fail and return NULL. This is already checked in pinmux_check_ops() so add a similar check in pinmux_func_name_to_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions.(CVE-2025-40030)
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies
When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free.
Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this:
drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; }
for (; i < fence_count; i++)
dma_fence_put(fences[i]);
Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it.
The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").
At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") noticed and attempted to fix.
But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case.
As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain.
While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.(CVE-2025-40096)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete x->tunnel as we delete x
The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.
We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.
Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.
A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.(CVE-2025-40215)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix livelock in synchronous file put from fuseblk workers
I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server:
cat /proc/372265/task/372313/stack
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
But the /weird/ part is that the fuseblk server threads are waiting for responses from itself:
cat /proc/372210/task/372232/stack
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that:
"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands.
Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.(CVE-2025-40220)
In the Linux kernel, the following vulnerability has been resolved:
fs/notify: call exportfs_encode_fid with s_umount
Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr.
This issue was found by syzkaller.
Race Condition Diagram:
Thread 1 Thread 2 -------- --------
generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL
|
| vfs_read()
| inotify_fdinfo()
| * inode get from mark *
| show_mark_fhandle(m, inode)
| exportfs_encode_fid(inode, ..)
| ovl_encode_fh(inode, ..)
| ovl_check_encode_origin(inode)
| * deref i_sb->s_root *
|
|
v
fsnotify_sb_delete(sb)
Which then leads to:
[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)
<snip registers, unreliable trace>
[ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240
IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path.
Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock.
This form of fix was suggested by Amir in 1.
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix unlikely race in gdlm_put_lock
In gdlm_put_lock(), there is a small window of time in which the DFL_UNMOUNT flag has been set but the lockspace hasn't been released, yet. In that window, dlm may still call gdlm_ast() and gdlm_bast(). To prevent it from dereferencing freed glock objects, only free the glock if the lockspace has actually been released.(CVE-2025-40242)
In the Linux kernel, the following vulnerability has been resolved:
devlink: rate: Unset parent pointer in devl_rate_nodes_destroy
The function devl_rate_nodes_destroy is documented to "Unset parent for
all rate objects". However, it was only calling the driver-specific
rate_leaf_parent_set or rate_node_parent_set ops and decrementing
the parent's refcount, without actually setting the
devlink_rate->parent pointer to NULL.
This leaves a dangling pointer in the devlink_rate struct, which cause
refcount error in netdevsim1 and mlx52. In addition, this is
inconsistent with the behavior of devlink_nl_rate_parent_node_set,
where the parent pointer is correctly cleared.
This patch fixes the issue by explicitly setting devlink_rate->parent
to NULL after notifying the driver, thus fulfilling the function's
documented behavior for all rate objects.
1 repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device
dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: <TASK> devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
2 devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core
dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: <TASK> devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-40251)
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |
rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)
In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix use-after-free race in fault handler
When a page fault occurs in a secret memory file created with
memfd_secret(2), the kernel will allocate a new folio for it, mark the
underlying page as not-present in the direct map, and add it to the file
mapping.
If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping.
If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault.
Fix the ordering to restore the direct map before the folio is freed.(CVE-2025-40272)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE
This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.(CVE-2025-40277)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()
In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied.
Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH.
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40294)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: validate skb length for unknown CC opcode
In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory.
The fix is to check skb->len before using skb->data.(CVE-2025-40301)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bcsp: receive data only if registered
Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace:
KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590
Call Trace:
<TASK>
hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627
tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290
tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.(CVE-2025-40308)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and "UAF".
Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.(CVE-2025-40318)
In the Linux kernel, the following vulnerability has been resolved:
futex: Don't leak robust_list pointer on exec race
sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process.
During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged.
A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec().
For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process.
This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk.
Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.(CVE-2025-40341)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: use lock accessing port_state and rport state
nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.(CVE-2025-40342)
In the Linux kernel, the following vulnerability has been resolved:
nvmet-fc: avoid scheduling association deletion twice
When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion.
The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion.
Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.(CVE-2025-40343)
In the Linux kernel, the following vulnerability has been resolved:
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
The syzbot reported issue in hfsplus_delete_cat():
[ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] slaballoc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] ---truncated---(CVE-2025-40351)
In the Linux kernel, the following vulnerability has been resolved:
riscv: stacktrace: Disable KASAN checks for non-current tasks
Unwinding the stack of a task other than current, KASAN would report "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"
There is a same issue on x86 and has been resolved by the commit 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks") The solution could be applied to RISC-V too.
This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23
[(CVE-2025-40358)
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Fix KASAN global-out-of-bounds warning
When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen.
================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850
Call Trace:
kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80
The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF.
WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)
So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue.(CVE-2025-40359)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-40361)
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Ensure XFD state on signal delivery
Sean reported 1 the following splat when running KVM tests:
WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Chao further identified 2 a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR.
When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption.
Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature.
This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible.
dhansen: minor changelog munging
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix softlockup in ftrace_module_enable
A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()").
Fix it the same way by adding cond_resched() in ftrace_module_enable.(CVE-2025-68173)
In the Linux kernel, the following vulnerability has been resolved:
amd/amdkfd: enhance kfd process check in switch partition
current switch partition only check if kfd_processes_table is empty. kfd_prcesses_table entry is deleted in kfd_process_notifier_release, but kfd_process tear down is in kfd_process_wq_release.
consider two processes:
Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node member Process B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw -> kfd_node tear down.
Process A and B may trigger a race as shown in dmesg log.
This patch is to resolve the race by adding an atomic kfd_process counter kfd_processes_count, it increment as create kfd process, decrement as finish kfd_process_wq_release.
v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds and bug fix. (Philip Yang)
[3966658.307702] divide error: 0000 [#1] SMP NOPTI [3966658.350818] i10nm_edac [3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted [3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] [3966658.362839] nfit [3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu] [3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 <f7> be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00 [3966658.380967] x86_pkg_temp_thermal [3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246 [3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000 [3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00 [3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4 [3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000 [3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800 [3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000 [3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0 [3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [3966658.391536] PKRU: 55555554 [3966658.391536] Call Trace: [3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu] [3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu] [3966658.399754] intel_powerclamp [3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu] [3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu] [3966658.410516] coretemp [3966658.434016] process_one_work+0x1ad/0x380 [3966658.434021] worker_thread+0x49/0x310 [3966658.438963] kvm_intel [3966658.446041] ? process_one_work+0x380/0x380 [3966658.446045] kthread+0x118/0x140 [3966658.446047] ? __kthread_bind_mask+0x60/0x60 [3966658.446050] ret_from_fork+0x1f/0x30 [3966658.446053] Modules linked in: kpatch_20765354(OEK) [3966658.455310] kvm [3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK) [3966658.473462] idxd_mdev [3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo ---truncated---(CVE-2025-68174)
In the Linux kernel, the following vulnerability has been resolved:
PCI: cadence: Check for the existence of cdns_pcie::ops before using it
cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops.
Hence, add a check to prevent NULL pointer dereference.
mani: reworded subject and description
In the Linux kernel, the following vulnerability has been resolved:
tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()
Use RCU to avoid a pair of atomic operations and a potential UAF on dst_dev()->flags.(CVE-2025-68188)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Add bpf_prog_run_data_pointers()
syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().
WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214
struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and data_end for cls_act_bpf").
drop_reason was added later.
Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end.(CVE-2025-68200)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: add seqadj extension for natted connections
Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq.
The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet }
chain prerouting {
type filter hook prerouting priority 0; policy accept;
tcp dport 21 ct state new ct helper set "ftp_helper"
}
} table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } }
chain postrouting {
type nat hook postrouting priority 100 ; policy accept;
tcp sport 21 snat ip prefix to ip saddr map {
192.168.13.2 : 192.168.100.1/32 }
}
}
Note that the ftp helper gets assigned after the dnat setup.
The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem.
Topoloy:
+-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+
ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection.
Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..
Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.(CVE-2025-68206)
In the Linux kernel, the following vulnerability has been resolved:
bpf: account for current allocated stack depth in widen_imprecise_scalars()
The usage pattern for widen_imprecise_scalars() looks as follows:
prev_st = find_prev_entry(env, ...);
queued_st = push_stack(...);
widen_imprecise_scalars(env, prev_st, queued_st);
Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case:
def main():
for i in 1..2:
foo(i) // same callsite, differnt param
def foo(i):
if i == 1:
use 128 bytes of stack
iterator based loop
Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds.(CVE-2025-68208)
In the Linux kernel, the following vulnerability has been resolved:
timers: Fix NULL function pointer race in timer_shutdown_sync()
There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers().
The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:
CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base()
The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers().
Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.(CVE-2025-68214)
In the Linux kernel, the following vulnerability has been resolved:
nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot
nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning.
Make sure this data is deallocated.(CVE-2025-68235)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced
When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn instruction, discard the exception and retry the instruction if the code stream is changed (e.g. by a different vCPU) between when the CPU executes the instruction and when KVM decodes the instruction to get the next RIP.
As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction"), failure to verify that the correct INTn instruction was decoded can effectively clobber guest state due to decoding the wrong instruction and thus specifying the wrong next RIP.
The bug most often manifests as "Oops: int3" panics on static branch checks in Linux guests. Enabling or disabling a static branch in Linux uses the kernel's "text poke" code patching mechanism. To modify code while other CPUs may be executing that code, Linux (temporarily) replaces the first byte of the original instruction with an int3 (opcode 0xcc), then patches in the new code stream except for the first byte, and finally replaces the int3 with the first byte of the new code stream. If a CPU hits the int3, i.e. executes the code while it's being modified, then the guest kernel must look up the RIP to determine how to handle the #BP, e.g. by emulating the new instruction. If the RIP is incorrect, then this lookup fails and the guest kernel panics.
The bug reproduces almost instantly by hacking the guest kernel to repeatedly check a static branch1 while running a drgn script2 on the host to constantly swap out the memory containing the guest's TSS.
In the Linux kernel, the following vulnerability has been resolved:
ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()
Fix a race between inline data destruction and block mapping.
The function ext4_destroy_inline_data_nolock() changes the inode data layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS. At the same time, another thread may execute ext4_map_blocks(), which tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks() or ext4_ind_map_blocks().
Without i_data_sem protection, ext4_ind_map_blocks() may receive inode with EXT4_INODE_EXTENTS flag and triggering assert.
kernel BUG at fs/ext4/indirect.c:546! EXT4-fs (loop2): unmounting filesystem. invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546
Call Trace: <TASK> ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2025-68261)
In the Linux kernel, the following vulnerability has been resolved:
ext4: refresh inline data size before write operations
The cached ei->i_inline_size can become stale between the initial size check and when ext4_update_inline_data()/ext4_create_inline_data() use it. Although ext4_get_max_inline_size() reads the correct value at the time of the check, concurrent xattr operations can modify i_inline_size before ext4_write_lock_xattr() is acquired.
This causes ext4_update_inline_data() and ext4_create_inline_data() to work with stale capacity values, leading to a BUG_ON() crash in ext4_write_inline_data():
kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
The race window: 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, i_inline_size changes to 40] 4. ext4_write_lock_xattr() acquires lock 5. ext4_update_inline_data() uses stale i_inline_size = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers
Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock() immediately after acquiring xattr_sem. This ensures ext4_update_inline_data() and ext4_create_inline_data() work with current values that are protected from concurrent modifications.
This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inline_data file while its xattrs are changing") which fixed i_inline_off staleness. This patch addresses the related i_inline_size staleness issue.(CVE-2025-68264)
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix admin request_queue lifetime
The namespaces can access the controller's admin request_queue, and stale references on the namespaces may exist after tearing down the controller. Ensure the admin request_queue is active by moving the controller's 'put' to after all controller references have been released to ensure no one is can access the request_queue. This fixes a reported use-after-free bug:
BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNED_MODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: <TASK> dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ? _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 ? blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 ? wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0 ? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 ? cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380 __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60 </TASK>(CVE-2025-68265)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix crash in process_v2_sparse_read() for encrypted directories
The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps:
sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure
(1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered
[ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] <TASK> [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] </TASK> [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---(CVE-2025-68297)
In the Linux kernel, the following vulnerability has been resolved:
PCI/AER: Fix NULL pointer access by aer_info
The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info->xxx will result in kernel panic. Fix it.(CVE-2025-68309)
In the Linux kernel, the following vulnerability has been resolved:
usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer
When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed.
The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed.
This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs().
The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().(CVE-2025-68331)
In the Linux kernel, the following vulnerability has been resolved:
jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted
There's issue when file system corrupted: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1289! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0 RSP: 0018:ffff888117aafa30 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534 RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010 RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028 R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0 Call Trace: <TASK> __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The above issue occurs with us in errors=continue mode when accompanied by storage failures. There have been many inconsistencies in the file system data. In the case of file system data inconsistency, for example, if the block bitmap of a referenced block is not set, it can lead to the situation where a block being committed is allocated and used again. As a result, the following condition will not be satisfied then trigger BUG_ON. Of course, it is entirely possible to construct a problematic image that can trigger this BUG_ON through specific operations. In fact, I have constructed such an image and easily reproduced this issue. Therefore, J_ASSERT() holds true only under ideal conditions, but it may not necessarily be satisfied in exceptional scenarios. Using J_ASSERT() directly in abnormal situations would cause the system to crash, which is clearly not what we want. So here we directly trigger a JBD abort instead of immediately invoking BUG_ON.(CVE-2025-68337)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid
Fixes a crash when layout is null during this call stack:
write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode
pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.(CVE-2025-68349)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to:
1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.
Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Prevent recursive memory reclaim
Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory.
Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue.
To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS.
The "meta" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt.
This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation").
Fixes xfstest generic/273.(CVE-2025-68356)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()
The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header.
If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic.
Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.(CVE-2025-68362)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check skb->transport_header is set in bpf_skb_check_mtu
The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used:
bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)
The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used:
WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb
For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").
This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.(CVE-2025-68363)
In the Linux kernel, the following vulnerability has been resolved:
coresight: ETR: Fix ETR buffer use-after-free issue
When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue.
Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.(CVE-2025-68376)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stackmap overflow check in __bpf_get_stackid()
Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.(CVE-2025-68378)
In the Linux kernel, the following vulnerability has been resolved:
crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id
Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.(CVE-2025-68724)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do not let BPF test infra emit invalid GSO types to stack
Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled.
We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place.
The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.(CVE-2025-68725)
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()
In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style.
Compile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix improper freeing of purex item
In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item().
The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc().
An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption.
Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.(CVE-2025-68741)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Free special fields when update [lru_,]percpu_hash maps
As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed.
Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value,_long' in 'pcpu_copy_value()'.(CVE-2025-68744)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Clear cmds after chip reset
Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems:
-
Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.
-
BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().
So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at __qla2x00_abort_all_cmds.(CVE-2025-68745)
In the Linux kernel, the following vulnerability has been resolved:
block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock
blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared.
Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also.
This results in deadlock between two threads with these stacktraces:
__schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20
__schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53
The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list.
The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever.
Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.(CVE-2025-68756)
In the Linux kernel, the following vulnerability has been resolved:
sched/deadline: only set free_cpus for online runqueues
Commit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpus to reflect rd->online") introduced the cpudl_set/clear_freecpu functions to allow the cpu_dl::free_cpus mask to be manipulated by the deadline scheduler class rq_on/offline callbacks so the mask would also reflect this state.
Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_mask from cpudl_find()") removed the check of the cpu_active_mask to save some processing on the premise that the cpudl::free_cpus mask already reflected the runqueue online state.
Unfortunately, there are cases where it is possible for the cpudl_clear function to set the free_cpus bit for a CPU when the deadline runqueue is offline. When this occurs while a CPU is connected to the default root domain the flag may retain the bad state after the CPU has been unplugged. Later, a different CPU that is transitioning through the default root domain may push a deadline task to the powered down CPU when cpudl_find sees its free_cpus bit is set. If this happens the task will not have the opportunity to run.
One example is outlined here: https://lore.kernel.org/lkml/(CVE-2025-68780)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: Reset t_task_cdb pointer in error case
If allocation of cmd->t_task_cdb fails, it remains NULL but is later dereferenced in the 'err' path.
In case of error, reset NULL t_task_cdb value to point at the default fixed-size buffer.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68782)
In the Linux kernel, the following vulnerability has been resolved:
iomap: adjust read range correctly for non-block-aligned positions
iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio.
Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.(CVE-2025-68794)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: NFSv4 file creation neglects setting ACL
An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: "the ACL attribute is set as given".
The issue occurs in nfsd_create_setattr(), which calls nfsd_attrs_valid() to determine whether to call nfsd_setattr(). However, nfsd_attrs_valid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsd_setattr() is skipped, and the POSIX ACL is never applied to the inode.
Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL.(CVE-2025-68803)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix filename leak in __io_openat_prep()
__io_openat_prep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak.
Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup.(CVE-2025-68814)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: fw_tracer, Validate format string parameters
Add validation for format string parameters in the firmware tracer to prevent potential security vulnerabilities and crashes from malformed format strings received from firmware.
The firmware tracer receives format strings from the device firmware and uses them to format trace messages. Without proper validation, bad firmware could provide format strings with invalid format specifiers (e.g., %s, %p, %n) that could lead to crashes, or other undefined behavior.
Add mlx5_tracer_validate_params() to validate that all format specifiers in trace strings are limited to safe integer/hex formats (%x, %d, %i, %u, %llx, %lx, etc.). Reject strings containing other format types that could be used to access arbitrary memory or cause crashes. Invalid format strings are added to the trace output for visibility with "BAD_FORMAT: " prefix.(CVE-2025-68816)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency
Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.(CVE-2025-68817)
In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"
This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.
The commit being reverted added code to __qla2x00_abort_all_cmds() to call sp->done() without holding a spinlock. But unlike the older code below it, this new code failed to check sp->cmd_type and just assumed TYPE_SRB, which results in a jump to an invalid pointer in target-mode with TYPE_TGT_CMD:
qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79b qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h. qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no buffer qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurred qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda. BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor instruction fetch in kernel mode PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1 Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206 RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000 RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0 RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045 R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40 R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400 FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 </TASK>
Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early within lock") added the spinlock back, because not having the lock caused a race and a crash. But qla2x00_abort_srb() in the switch below already checks for qla2x00_chip_is_down() and handles it the same way, so the code above the switch is now redundant and still buggy in target-mode. Remove it.(CVE-2025-68818)
In the Linux kernel, the following vulnerability has been resolved:
shmem: fix recovery on rename failures
maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange().
Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout().
Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton.
For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations.
For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations.
That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().(CVE-2025-71072)
In the Linux kernel, the following vulnerability has been resolved:
tpm: Cap the number of PCR banks
tpm2_get_pcr_allocation() does not cap any upper limit for the number of banks. Cap the limit to eight banks so that out of bounds values coming from external I/O cause on only limited harm.(CVE-2025-71077)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in update_target_expiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 </IRQ>
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---(CVE-2025-71104)
In the Linux kernel, the following vulnerability has been resolved:
libceph: make decode_pool() more resilient against corrupted osdmaps
If the osdmap is (maliciously) corrupted such that the encoded length of ceph_pg_pool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value.
This patch adds explicit bounds checks for each field that is decoded or skipped.(CVE-2025-71116)
In the Linux kernel, the following vulnerability has been resolved:
crypto: seqiv - Do not use req->iv after crypto_aead_encrypt
As soon as crypto_aead_encrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.
Instead of checking req->iv against info, create a new variable unaligned_info and use it for that purpose instead.(CVE-2025-71131)
In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: change all pageblocks migrate type on coalescing
When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed.
However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged.
That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced.
[ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2 larl %r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5 brasl %r14,0000034997378f60 #00000349976fa5fc: af000000 mc 0,0 >00000349976fa600: a7f4ff4c brc 15,00000349976fa498 00000349976fa604: b9040026 lgr %r2,%r6 00000349976fa608: c0300088317f larl %r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1 brasl %r14,00000349976b13d0 00000349976fa614: af000000 mc 0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---(CVE-2025-71134)
In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix a memory leak in tpm2_load_cmd
'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode' but it is not freed in the failure paths. Address this by wrapping the blob into with a cleanup helper.(CVE-2025-71147)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: correctly handle io_poll_add() return value on update
When the core of io_uring was updated to handle completions consistently and with fixed return codes, the POLL_REMOVE opcode with updates got slightly broken. If a POLL_ADD is pending and then POLL_REMOVE is used to update the events of that request, if that update causes the POLL_ADD to now trigger, then that completion is lost and a CQE is never posted.
Additionally, ensure that if an update does cause an existing POLL_ADD to complete, that the completion value isn't always overwritten with -ECANCELED. For that case, whatever io_poll_add() set the value to should just be retained.(CVE-2025-71149)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Fix refcount leak when invalid session is found on session lookup
When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.(CVE-2025-71150)
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: properly keep track of conduit reference
Problem description
DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.
There are two distinct problems.
- The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:
(unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind
we see these lines in the output diff which appear only with the patch applied:
kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)
- After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).
Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.
So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.
Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.
As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.
History and blame attribution
The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.
We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---(CVE-2025-71152)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: rtl8150: fix memory leak on usb_submit_urb() failure
In async_set_registers(), when usb_submit_urb() fails, the allocated async_req structure and URB are not freed, causing a memory leak.
The completion callback async_set_reg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked.
Fix this by freeing both the URB and the request structure in the error path when usb_submit_urb() fails.(CVE-2025-71154)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix bsg_done() causing double free
Kernel panic observed on system,
[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: error_code(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] <TASK> [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825232] ? sg_copy_buffer+0xc8/0x110 [5353358.825236] ? __die_body.cold+0x8/0xd [5353358.825238] ? page_fault_oops+0x134/0x170 [5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110 [5353358.825244] ? exc_page_fault+0xa8/0x150 [5353358.825247] ? asm_exc_page_fault+0x22/0x30 [5353358.825252] ? memcpy_erms+0x6/0x10 [5353358.825253] sg_copy_buffer+0xc8/0x110 [5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx]
Most routines in qla_bsg.c call bsg_done() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().(CVE-2025-71238)
In the Linux kernel, the following vulnerability has been resolved:
wifi: avoid kernel-infoleak from struct iw_point
struct iw_point has a 32bit hole on 64bit arches.
struct iw_point { void __user pointer; / Pointer to the data (in user space) / __u16 length; / number of fields or size in bytes / __u16 flags; / Optional params */ };
Make sure to zero the structure to avoid disclosing 32bits of kernel data to user space.(CVE-2026-22978)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: provide locking for v4_end_grace
Writing to v4_end_grace can race with server shutdown and result in memory being accessed after it was freed - reclaim_str_hashtbl in particularly.
We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is held while client_tracking_op->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4_end_grace, resulting in a deadlock.
nfsd4_end_grace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4_end_grace() might access.
However, we must be sure that writing to v4_end_grace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->client_lock. It is set only while it is safe to make client tracking calls, and v4_end_grace only schedules work while the flag is set with the spinlock held.
So this patch adds a nfsd_net field "client_tracking_active" which is set as described. Another field "grace_end_forced", is set when v4_end_grace is written. After this is set, and providing client_tracking_active is set, the laundromat is scheduled. This "grace_end_forced" field bypasses other checks for whether the grace period has finished.
This resolves a race which can result in use-after-free.(CVE-2026-22980)
In the Linux kernel, the following vulnerability has been resolved:
libceph: replace overzealous BUG_ON in osdmap_apply_incremental()
If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.(CVE-2026-22990)
In the Linux kernel, the following vulnerability has been resolved:
libceph: return the handler error from mon_handle_auth_done()
Currently any error from ceph_auth_handle_reply_done() is propagated via finish_auth() but isn't returned from mon_handle_auth_done(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setup_crypto() and later lead to a NULL pointer dereference inside of prepare_auth_signature().(CVE-2026-22992)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv
mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5e_dev and get mdev from the containing mlx5_adev aux device structure.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_remove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: <TASK> device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-22996)
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec
Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs.
The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.
Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL
The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated(CVE-2026-22998)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix crash on profile change rollback failure
mlx5e_netdev_change_profile can fail to attach a new profile and can fail to rollback to old profile, in such case, we could end up with a dangling netdev with a fully reset netdev_priv. A retry to change profile, e.g. another attempt to call mlx5e_netdev_change_profile via switchdev mode change, will crash trying to access the now NULL priv->mdev.
This fix allows mlx5e_netdev_change_profile() to handle previous failures and an empty priv, by not assuming priv is valid.
Pass netdev and mdev to all flows requiring mlx5e_netdev_change_profile() and avoid passing priv. In mlx5e_netdev_change_profile() check if current priv is valid, and if not, just attach the new profile without trying to access the old one.
This fixes the following oops, when enabling switchdev mode for the 2nd time after first time failure:
## Enabling switchdev mode first time:
mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 ^^^^^^^^ mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)
## retry: Enabling switchdev mode 2nd time:
mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload BUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_detach_netdev+0x3c/0x90 Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdfb8495047(CVE-2026-23000)
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1
When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel.
E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:
------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's call to fpu_update_guest_xfd().
and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:
------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component):
If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).
Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD.
Therefore, XFD can only go out of sync with XSTATE_BV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.
[Move clea ---truncated---(CVE-2026-23005)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv
mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails.
Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a valid netdev.
On mlx5e_remove: Check validity of priv->profile, before attempting to cleanup any resources that might be not there.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0 RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10 R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0 R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400 FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-23035)
In the Linux kernel, the following vulnerability has been resolved:
crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec
authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS).
Add a minimum AAD length check to fail fast on invalid inputs.(CVE-2026-23060)
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: fix potential underflow in virtio_transport_get_credit()
The credit calculation in virtio_transport_get_credit() uses unsigned arithmetic:
ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);
If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle.
Reuse virtio_transport_has_space() which already handles this case and add a comment to make it clear why we are doing that.
[Stefano: use virtio_transport_has_space() instead of duplicating the code] Stefano: tweak the commit message
In the Linux kernel, the following vulnerability has been resolved:
regmap: Fix race condition in hwspinlock irqsave routine
Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner.
Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.(CVE-2026-23071)
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: cap TX credit to local buffer size
The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.
On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base.
Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc.
This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings.
On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited.
With this patch applied:
Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB
After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB
Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive.
Compatibility with non-virtio transports:
-
VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured.
-
Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes.
-
The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport.
This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have.
[Stefano: small adjustments after changing the previous patch] Stefano: tweak the commit message
In the Linux kernel, the following vulnerability has been resolved:
bonding: limit BOND_MODE_8023AD to Ethernet devices
BOND_MODE_8023AD makes sense for ARPHRD_ETHER only.
syzbot reported:
BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497
CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 _syssendmsg+0x505/0x820 net/socket.c:2592 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e </TASK>
The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40(CVE-2026-23099)
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Make the addrs_lock be per port
Make the addrs_lock be per port, not per ipvlan dev.
Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So
1) Introduce per-port addrs_lock.
2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close)
This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause:
1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock.
2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks
This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.(CVE-2026-23103)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag
This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.(CVE-2026-23105)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()
nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required.
nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones.
Compare the non-catchall activate callback, which is correct:
nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; / skip active, process inactive /
With the buggy catchall version:
nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; / skip inactive, process active /
The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free.
This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES.
Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.(CVE-2026-23111)
In the Linux kernel, the following vulnerability has been resolved:
l2tp: avoid one data-race in l2tp_tunnel_del_work()
We should read sk->sk_socket only when dealing with kernel sockets.
syzbot reported the following data-race:
BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release
write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 _fput+0x1c/0x30 fs/filetable.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
value changed: 0xffff88811b818000 -> 0x0000000000000000(CVE-2026-23120)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: annotate data-race in ndisc_router_discovery()
syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock 1
This looks fine, IFLA_INET6_RA_MTU is best effort.
Add READ_ONCE()/WRITE_ONCE() to document the race.
Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.
1 BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery
read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ...
write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ...
value changed: 0x00000000 -> 0xe5400659(CVE-2026-23124)
In the Linux kernel, the following vulnerability has been resolved:
netdevsim: fix a race issue related to the operation on bpf_bound_progs list
The netdevsim driver lacks a protection mechanism for operations on the bpf_bound_progs list. When the nsim_bpf_create_prog() performs list_add_tail, it is possible that nsim_bpf_destroy_prog() is simultaneously performs list_del. Concurrent operations on the list may lead to list corruption and trigger a kernel crash as follows:
[ 417.290971] kernel BUG at lib/list_debug.c:62! [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 417.291007] Workqueue: events bpf_prog_free_deferred [ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0 [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8 [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246 [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000 [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180 [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003 [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20 [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000 [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000 [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0 [ 417.291088] PKRU: 55555554 [ 417.291091] Call Trace: [ 417.291096] <TASK> [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim] [ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80 [ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0 [ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0 [ 417.291178] process_one_work+0x18a/0x3a0 [ 417.291188] worker_thread+0x27b/0x3a0 [ 417.291197] ? __pfx_worker_thread+0x10/0x10 [ 417.291207] kthread+0xe5/0x120 [ 417.291214] ? __pfx_kthread+0x10/0x10 [ 417.291221] ret_from_fork+0x31/0x50 [ 417.291230] ? __pfx_kthread+0x10/0x10 [ 417.291236] ret_from_fork_asm+0x1a/0x30 [ 417.291246] </TASK>
Add a mutex lock, to prevent simultaneous addition and deletion operations on the list.(CVE-2026-23126)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: fix dma_free_coherent() pointer
dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.(CVE-2026-23133)
In the Linux kernel, the following vulnerability has been resolved:
libceph: reset sparse-read state in osd_fault()
When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state.
If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like:
libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read
Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state.(CVE-2026-23136)
In the Linux kernel, the following vulnerability has been resolved:
of: unittest: Fix memory leak in unittest_data_add()
In unittest_data_add(), if of_resolve_phandles() fails, the allocated unittest_data is not freed, leading to a memory leak.
Fix this by using scope-based cleanup helper __free(kfree) for automatic resource cleanup. This ensures unittest_data is automatically freed when it goes out of scope in error paths.
For the success path, use retain_and_null_ptr() to transfer ownership of the memory to the device tree and prevent double freeing.(CVE-2026-23137)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add recursion protection in kernel stack trace recording
A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again.
Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI).
Have the stack trace code use the interrupt context to protect against recursion.
Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately.(CVE-2026-23138)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conncount: update last_gc only when GC has been performed
Currently last_gc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely.
Update the last_gc value only when a GC has been actually performed.(CVE-2026-23139)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref
The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.(CVE-2026-23145)
In the Linux kernel, the following vulnerability has been resolved:
net: fix segmentation of forwarding fraglist GRO
This patch enhances GSO segment handling by properly checking the SKB_GSO_DODGY flag for frag_list GSO packets, addressing low throughput issues observed when a station accesses IPv4 servers via hotspots with an IPv6-only upstream interface.
Specifically, it fixes a bug in GSO segmentation when forwarding GRO packets containing a frag_list. The function skb_segment_list cannot correctly process GRO skbs that have been converted by XLAT, since XLAT only translates the header of the head skb. Consequently, skbs in the frag_list may remain untranslated, resulting in protocol inconsistencies and reduced throughput.
To address this, the patch explicitly sets the SKB_GSO_DODGY flag for GSO packets in XLAT's IPv4/IPv6 protocol translation helpers (bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSO packets as potentially modified after protocol translation. As a result, GSO segmentation will avoid using skb_segment_list and instead falls back to skb_segment for packets with the SKB_GSO_DODGY flag. This ensures that only safe and fully translated frag_list packets are processed by skb_segment_list, resolving protocol inconsistencies and improving throughput when forwarding GRO packets converted by XLAT.(CVE-2026-23154)
In the Linux kernel, the following vulnerability has been resolved:
efivarfs: fix error propagation in efivar_entry_get()
efivar_entry_get() always returns success even if the underlying __efivar_entry_get() fails, masking errors.
This may result in uninitialized heap memory being copied to userspace in the efivarfs_file_read() path.
Fix it by returning the error from __efivar_entry_get().(CVE-2026-23156)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()
syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup()
Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready.
list_splice_init_rcu() can not be called here while holding pernet->lock spinlock.
Many thanks to Eulgyu Kim for providing a repro and testing our patches.(CVE-2026-23169)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: TC, delete flows only for existing peers
When deleting TC steering flows, iterate only over actual devcom peers instead of assuming all possible ports exist. This avoids touching non-existent peers and ensures cleanup is limited to devices the driver is currently connected to.
BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: <TASK> mlx5e_tc_del_flow+0x46/0x270 [mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core] mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core] tc_setup_cb_reoffload+0x20/0x80 fl_reoffload+0x26f/0x2f0 [cls_flower] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] tcf_block_playback_offloads+0x9e/0x1c0 tcf_block_unbind+0x7b/0xd0 tcf_block_setup+0x186/0x1d0 tcf_block_offload_cmd.isra.0+0xef/0x130 tcf_block_offload_unbind+0x43/0x70 __tcf_block_put+0x85/0x160 ingress_destroy+0x32/0x110 [sch_ingress] __qdisc_destroy+0x44/0x100 qdisc_graft+0x22b/0x610 tc_get_qdisc+0x183/0x4d0 rtnetlink_rcv_msg+0x2d7/0x3d0 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x249/0x320 ? __alloc_skb+0x102/0x1f0 netlink_sendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60 _syssendmsg+0x1ef/0x230 ? copy_msghdr_from_user+0x6c/0xa0 _sys_sendmsg+0x7f/0xc0 ? sysrecvmsg+0x8a/0xc0 ? sys_sendto+0x119/0x180 __sys_sendmsg+0x61/0xb0 do_syscall_64+0x55/0x640 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764 RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780(CVE-2026-23173)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: aloop: Fix racy access at PCM trigger
The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers.
For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.(CVE-2026-23191)
In the Linux kernel, the following vulnerability has been resolved:
KVM: Don't clobber irqfd routing type when deassigning irqfd
When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone.
As a bonus, checking that the irqfd is active provides a convenient location for documenting why KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens before the eventfd is detached), it will no longer receive updates via kvm_irq_routing_update(), and so KVM could deliver an event using stale routing information (relative to KVM_SET_GSI_ROUTING returning to userspace).
As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information.
As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd.
Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irq_bypass_data being NULL when read by avic_update_iommu_vcpu_affinity():
BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: <TASK> avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b </TASK> ---[ end trace 0000000000000000 ]---
If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment.
list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: <TASK> avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa ---truncated---(CVE-2026-23198)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_u32: use skb_header_pointer_careful()
skb_header_pointer() does not fully validate negative @offset values.
Use skb_header_pointer_careful() instead.
GangMin Kim provided a report and a repro fooling u32_classify():
BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221(CVE-2026-23204)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Prevent excessive number of frames
In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize1 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot 1.
Added a check for the number of single data URB frames when calculating the number of frames to prevent 1.
1 BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611 prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333(CVE-2026-23208)
In the Linux kernel, the following vulnerability has been resolved:
bonding: annotate data-races around slave->last_rx
slave->last_rx and slave->target_last_arp_rx[...] can be read and written locklessly. Add READ_ONCE() and WRITE_ONCE() annotations.
syzbot reported:
BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate
write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 ...
write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 br_netif_receive_skb net/bridge/br_input.c:30 [inline] NF_HOOK include/linux/netfilter.h:318 [inline] ...
value changed: 0x0000000100005365 -> 0x0000000100005366(CVE-2026-23212)
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix use-after-free in driver_override_show()
The driver_override_show() function reads the driver_override string without holding the device_lock. However, driver_override_store() uses driver_set_override(), which modifies and frees the string while holding the device_lock.
This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function.
Fix this by holding the device_lock around the read operation.(CVE-2026-23221)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: split cached_fid bitfields to avoid shared-byte RMW races
is_open, has_lease and on_list are stored in the same bitfield byte in
struct cached_fid but are updated in different code paths that may run
concurrently. Bitfield assignments generate byte read–modify–write
operations (e.g. orb $mask, addr on x86_64), so updating one flag can
restore stale values of the others.
A possible interleaving is: CPU1: load old byte (has_lease=1, on_list=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits
To avoid this class of races, convert these flags to separate bool fields.(CVE-2026-23230)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"perf-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-144.0.0.139.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"perf-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-144.0.0.139.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/s390: Implement blocking domain\n\nThis fixes a crash when surprise hot-unplugging a PCI device. This crash\nhappens because during hot-unplug __iommu_group_set_domain_nofail()\nattaching the default domain fails when the platform no longer\nrecognizes the device as it has already been removed and we end up with\na NULL domain pointer and UAF. This is exactly the case referred to in\nthe second comment in __iommu_device_set_domain() and just as stated\nthere if we can instead attach the blocking domain the UAF is prevented\nas this can handle the already removed device. Implement the blocking\ndomain to use this handling. With this change, the crash is fixed but\nwe still hit a warning attempting to change DMA ownership on a blocked\ndevice.(CVE-2024-53232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu: Fix two issues in iommu_copy_struct_from_user()\n\nIn the review for iommu_copy_struct_to_user() helper, Matt pointed out that\na NULL pointer should be rejected prior to dereferencing it:\nhttps://lore.kernel.org/all/(CVE-2025-37900)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Avoid race in open_cached_dir with lease breaks\n\nA pre-existing valid cfid returned from find_or_create_cached_dir might\nrace with a lease break, meaning open_cached_dir doesn\u0026apos;t consider it\nvalid, and thinks it\u0026apos;s newly-constructed. This leaks a dentry reference\nif the allocation occurs before the queued lease break work runs.\n\nAvoid the race by extending holding the cfid_list_lock across\nfind_or_create_cached_dir and when the result is checked.(CVE-2025-37954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: prio: fix a race in prio_tune()\n\nGerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n | [5]: lock root\n | [6]: rehash\n | [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent\u0026apos;s qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.(CVE-2025-38083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix potential deadlock in MR deregistration\n\nThe issue arises when kzalloc() is invoked while holding umem_mutex or\nany other lock acquired under umem_mutex. This is problematic because\nkzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke\nmmu_notifier_invalidate_range_start(). This function can lead to\nmlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,\nresulting in a deadlock.\n\nThe problematic flow:\n CPU0 | CPU1\n---------------------------------------|------------------------------------------------\nmlx5_ib_dereg_mr() |\n \u2192 revoke_mr() |\n \u2192 mutex_lock(\u0026amp;umem_odp-\u0026gt;umem_mutex) |\n | mlx5_mkey_cache_init()\n | \u2192 mutex_lock(\u0026amp;dev-\u0026gt;cache.rb_lock)\n | \u2192 mlx5r_cache_create_ent_locked()\n | \u2192 kzalloc(GFP_KERNEL)\n | \u2192 fs_reclaim()\n | \u2192 mmu_notifier_invalidate_range_start()\n | \u2192 mlx5_ib_invalidate_range()\n | \u2192 mutex_lock(\u0026amp;umem_odp-\u0026gt;umem_mutex)\n \u2192 cache_ent_find_and_store() |\n \u2192 mutex_lock(\u0026amp;dev-\u0026gt;cache.rb_lock) |\n\nAdditionally, when kzalloc() is called from within\ncache_ent_find_and_store(), we encounter the same deadlock due to\nre-acquisition of umem_mutex.\n\nSolve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()\nand before acquiring rb_lock. This ensures that we don\u0026apos;t hold\numem_mutex while performing memory allocations that could trigger\nthe reclaim path.\n\nThis change prevents the deadlock by ensuring proper lock ordering and\navoiding holding locks during memory allocation operations that could\ntrigger the reclaim path.\n\nThe following lockdep warning demonstrates the deadlock:\n\n python3/20557 is trying to acquire lock:\n ffff888387542128 (\u0026amp;umem_odp-\u0026gt;umem_mutex){+.+.}-{4:4}, at:\n mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]\n\n but task is already holding lock:\n ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:\n unmap_vmas+0x7b/0x1a0\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u0026gt; #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:\n fs_reclaim_acquire+0x60/0xd0\n mem_cgroup_css_alloc+0x6f/0x9b0\n cgroup_init_subsys+0xa4/0x240\n cgroup_init+0x1c8/0x510\n start_kernel+0x747/0x760\n x86_64_start_reservations+0x25/0x30\n x86_64_start_kernel+0x73/0x80\n common_startup_64+0x129/0x138\n\n -\u0026gt; #2 (fs_reclaim){+.+.}-{0:0}:\n fs_reclaim_acquire+0x91/0xd0\n __kmalloc_cache_noprof+0x4d/0x4c0\n mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]\n mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]\n mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]\n __mlx5_ib_add+0x4b/0x190 [mlx5_ib]\n mlx5r_probe+0xd9/0x320 [mlx5_ib]\n auxiliary_bus_probe+0x42/0x70\n really_probe+0xdb/0x360\n __driver_probe_device+0x8f/0x130\n driver_probe_device+0x1f/0xb0\n __driver_attach+0xd4/0x1f0\n bus_for_each_dev+0x79/0xd0\n bus_add_driver+0xf0/0x200\n driver_register+0x6e/0xc0\n __auxiliary_driver_register+0x6a/0xc0\n do_one_initcall+0x5e/0x390\n do_init_module+0x88/0x240\n init_module_from_file+0x85/0xc0\n idempotent_init_module+0x104/0x300\n __x64_sys_finit_module+0x68/0xc0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n -\u0026gt; #1 (\u0026amp;dev-\u0026gt;cache.rb_lock){+.+.}-{4:4}:\n __mutex_lock+0x98/0xf10\n __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]\n mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]\n ib_dereg_mr_user+0x85/0x1f0 [ib_core]\n \n---truncated---(CVE-2025-38373)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Harden s32ton() against conversion to 0 bits\n\nTesting by the syzbot fuzzer showed that the HID core gets a\nshift-out-of-bounds exception when it tries to convert a 32-bit\nquantity to a 0-bit quantity. Ideally this should never occur, but\nthere are buggy devices and some might have a report field with size\nset to zero; we shouldn\u0026apos;t reject the report or the device just because\nof that.\n\nInstead, harden the s32ton() routine so that it returns a reasonable\nresult instead of crashing when it is called with the number of bits\nset to 0 -- the same as what snto32() does.(CVE-2025-38556)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject narrower access to pointer ctx fields\n\nThe following BPF program, simplified from a syzkaller repro, causes a\nkernel warning:\n\n r0 = *(u8 *)(r1 + 169);\n exit;\n\nWith pointer field sk being at offset 168 in __sk_buff. This access is\ndetected as a narrower read in bpf_skb_is_valid_access because it\ndoesn\u0026apos;t match offsetof(struct __sk_buff, sk). It is therefore allowed\nand later proceeds to bpf_convert_ctx_access. Note that for the\n\u0026quot;is_narrower_load\u0026quot; case in the convert_ctx_accesses(), the insn-\u0026gt;off\nis aligned, so the cnt may not be 0 because it matches the\noffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,\nthe target_size stays 0 and the verifier errors with a kernel warning:\n\n verifier bug: error during ctx access conversion(1)\n\nThis patch fixes that to return a proper \u0026quot;invalid bpf_context access\noff=X size=Y\u0026quot; error on the load instruction.\n\nThe same issue affects multiple other fields in context structures that\nallow narrow access. Some other non-affected fields (for sk_msg,\nsk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for\nconsistency.\n\nNote this syzkaller crash was reported in the \u0026quot;Closes\u0026quot; link below, which\nused to be about a different bug, fixed in\ncommit fce7bd8e385a (\u0026quot;bpf/verifier: Handle BPF_LOAD_ACQ instructions\nin insn_def_regno()\u0026quot;). Because syzbot somehow confused the two bugs,\nthe new crash and repro didn\u0026apos;t get reported to the mailing list.(CVE-2025-38591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: No more self recovery\n\nWhen a node withdraws and it turns out that it is the only node that has\nthe filesystem mounted, gfs2 currently tries to replay the local journal\nto bring the filesystem back into a consistent state. Not only is that\na very bad idea, it has also never worked because gfs2_recover_func()\nwill refuse to do anything during a withdraw.\n\nHowever, before even getting to this point, gfs2_recover_func()\ndereferences sdp-\u0026gt;sd_jdesc-\u0026gt;jd_inode. This was a use-after-free before\ncommit 04133b607a78 (\u0026quot;gfs2: Prevent double iput for journal on error\u0026quot;)\nand is a NULL pointer dereference since then.\n\nSimply get rid of self recovery to fix that.(CVE-2025-38659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/net: commit partial buffers on retry\n\nRing provided buffers are potentially only valid within the single\nexecution context in which they were acquired. io_uring deals with this\nand invalidates them on retry. But on the networking side, if\nMSG_WAITALL is set, or if the socket is of the streaming type and too\nlittle was processed, then it will hang on to the buffer rather than\nrecycle or commit it. This is problematic for two reasons:\n\n1) If someone unregisters the provided buffer ring before a later retry,\n then the req-\u0026gt;buf_list will no longer be valid.\n\n2) If multiple sockers are using the same buffer group, then multiple\n receives can consume the same memory. This can cause data corruption\n in the application, as either receive could land in the same\n userspace buffer.\n\nFix this by disallowing partial retries from pinning a provided buffer\nacross multiple executions, if ring provided buffers are used.(CVE-2025-38730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()\n\nIn the interrupt handler rain_interrupt(), the buffer full check on\nrain-\u0026gt;buf_len is performed before acquiring rain-\u0026gt;buf_lock. This\ncreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as\nrain-\u0026gt;buf_len is concurrently accessed and modified in the work\nhandler rain_irq_work_handler() under the same lock.\n\nMultiple interrupt invocations can race, with each reading buf_len\nbefore it becomes full and then proceeding. This can lead to both\ninterrupts attempting to write to the buffer, incrementing buf_len\nbeyond its capacity (DATA_SIZE) and causing a buffer overflow.\n\nFix this bug by moving the spin_lock() to before the buffer full\ncheck. This ensures that the check and the subsequent buffer modification\nare performed atomically, preventing the race condition. An corresponding\nspin_unlock() is added to the overflow path to correctly release the\nlock.\n\nThis possible bug was found by an experimental static analysis tool\ndeveloped by our team.(CVE-2025-39713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/pgtbl: Fix possible race while increase page table level\n\nThe AMD IOMMU host page table implementation supports dynamic page table levels\n(up to 6 levels), starting with a 3-level configuration that expands based on\nIOVA address. The kernel maintains a root pointer and current page table level\nto enable proper page table walks in alloc_pte()/fetch_pte() operations.\n\nThe IOMMU IOVA allocator initially starts with 32-bit address and onces its\nexhuasted it switches to 64-bit address (max address is determined based\non IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU\ndriver increases page table level.\n\nBut in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads\npgtable-\u0026gt;[root/mode] without lock. So its possible that in exteme corner case,\nwhen increase_address_space() is updating pgtable-\u0026gt;[root/mode], fetch_pte()\nreads wrong page table level (pgtable-\u0026gt;mode). It does compare the value with\nlevel encoded in page table and returns NULL. This will result is\niommu_unmap ops to fail and upper layer may retry/log WARN_ON.\n\nCPU 0 CPU 1\n------ ------\nmap pages unmap pages\nalloc_pte() -\u0026gt; increase_address_space() iommu_v1_unmap_pages() -\u0026gt; fetch_pte()\n pgtable-\u0026gt;root = pte (new root value)\n READ pgtable-\u0026gt;[mode/root]\n\t\t\t\t\t Reads new root, old mode\n Updates mode (pgtable-\u0026gt;mode += 1)\n\nSince Page table level updates are infrequent and already synchronized with a\nspinlock, implement seqcount to enable lock-free read operations on the read path.(CVE-2025-39961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: check the return value of pinmux_ops::get_function_name()\n\nWhile the API contract in docs doesn\u0026apos;t specify it explicitly, the\ngeneric implementation of the get_function_name() callback from struct\npinmux_ops - pinmux_generic_get_function_name() - can fail and return\nNULL. This is already checked in pinmux_check_ops() so add a similar\ncheck in pinmux_func_name_to_selector() instead of passing the returned\npointer right down to strcmp() where the NULL can get dereferenced. This\nis normal operation when adding new pinfunctions.(CVE-2025-40030)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies\n\nWhen adding dependencies with drm_sched_job_add_dependency(), that\nfunction consumes the fence reference both on success and failure, so in\nthe latter case the dma_fence_put() on the error path (xarray failed to\nexpand) is a double free.\n\nInterestingly this bug appears to have been present ever since\ncommit ebd5f74255b9 (\u0026quot;drm/sched: Add dependency tracking\u0026quot;), since the code\nback then looked like this:\n\ndrm_sched_job_add_implicit_dependencies():\n...\n for (i = 0; i \u0026lt; fence_count; i++) {\n ret = drm_sched_job_add_dependency(job, fences[i]);\n if (ret)\n break;\n }\n\n for (; i \u0026lt; fence_count; i++)\n dma_fence_put(fences[i]);\n\nWhich means for the failing \u0026apos;i\u0026apos; the dma_fence_put was already a double\nfree. Possibly there were no users at that time, or the test cases were\ninsufficient to hit it.\n\nThe bug was then only noticed and fixed after\ncommit 9c2ba265352a (\u0026quot;drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2\u0026quot;)\nlanded, with its fixup of\ncommit 4eaf02d6076c (\u0026quot;drm/scheduler: fix drm_sched_job_add_implicit_dependencies\u0026quot;).\n\nAt that point it was a slightly different flavour of a double free, which\ncommit 963d0b356935 (\u0026quot;drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder\u0026quot;)\nnoticed and attempted to fix.\n\nBut it only moved the double free from happening inside the\ndrm_sched_job_add_dependency(), when releasing the reference not yet\nobtained, to the caller, when releasing the reference already released by\nthe former in the failure case.\n\nAs such it is not easy to identify the right target for the fixes tag so\nlets keep it simple and just continue the chain.\n\nWhile fixing we also improve the comment and explain the reason for taking\nthe reference and not dropping it.(CVE-2025-40096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete x-\u0026gt;tunnel as we delete x\n\nThe ipcomp fallback tunnels currently get deleted (from the various\nlists and hashtables) as the last user state that needed that fallback\nis destroyed (not deleted). If a reference to that user state still\nexists, the fallback state will remain on the hashtables/lists,\ntriggering the WARN in xfrm_state_fini. Because of those remaining\nreferences, the fix in commit f75a2804da39 (\u0026quot;xfrm: destroy xfrm_state\nsynchronously on net exit path\u0026quot;) is not complete.\n\nWe recently fixed one such situation in TCP due to defered freeing of\nskbs (commit 9b6412e6979f (\u0026quot;tcp: drop secpath at the same time as we\ncurrently drop dst\u0026quot;)). This can also happen due to IP reassembly: skbs\nwith a secpath remain on the reassembly queue until netns\ndestruction. If we can\u0026apos;t guarantee that the queues are flushed by the\ntime xfrm_state_fini runs, there may still be references to a (user)\nxfrm_state, preventing the timely deletion of the corresponding\nfallback state.\n\nInstead of chasing each instance of skbs holding a secpath one by one,\nthis patch fixes the issue directly within xfrm, by deleting the\nfallback state as soon as the last user state depending on it has been\ndeleted. Destruction will still happen when the final reference is\ndropped.\n\nA separate lockdep class for the fallback state is required since\nwe\u0026apos;re going to lock x-\u0026gt;tunnel while x is locked.(CVE-2025-40215)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix livelock in synchronous file put from fuseblk workers\n\nI observed a hang when running generic/323 against a fuseblk server.\nThis test opens a file, initiates a lot of AIO writes to that file\ndescriptor, and closes the file descriptor before the writes complete.\nUnsurprisingly, the AIO exerciser threads are mostly stuck waiting for\nresponses from the fuseblk server:\n\n# cat /proc/372265/task/372313/stack\n[\u0026lt;0\u0026gt;] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u0026lt;0\u0026gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_do_getattr+0xfc/0x1f0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_file_read_iter+0xbe/0x1c0 [fuse]\n[\u0026lt;0\u0026gt;] aio_read+0x130/0x1e0\n[\u0026lt;0\u0026gt;] io_submit_one+0x542/0x860\n[\u0026lt;0\u0026gt;] __x64_sys_io_submit+0x98/0x1a0\n[\u0026lt;0\u0026gt;] do_syscall_64+0x37/0xf0\n[\u0026lt;0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nBut the /weird/ part is that the fuseblk server threads are waiting for\nresponses from itself:\n\n# cat /proc/372210/task/372232/stack\n[\u0026lt;0\u0026gt;] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u0026lt;0\u0026gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_file_put+0x9a/0xd0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_release+0x36/0x50 [fuse]\n[\u0026lt;0\u0026gt;] __fput+0xec/0x2b0\n[\u0026lt;0\u0026gt;] task_work_run+0x55/0x90\n[\u0026lt;0\u0026gt;] syscall_exit_to_user_mode+0xe9/0x100\n[\u0026lt;0\u0026gt;] do_syscall_64+0x43/0xf0\n[\u0026lt;0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe fuseblk server is fuse2fs so there\u0026apos;s nothing all that exciting in\nthe server itself. So why is the fuse server calling fuse_file_put?\nThe commit message for the fstest sheds some light on that:\n\n\u0026quot;By closing the file descriptor before calling io_destroy, you pretty\nmuch guarantee that the last put on the ioctx will be done in interrupt\ncontext (during I/O completion).\n\nAha. AIO fgets a new struct file from the fd when it queues the ioctx.\nThe completion of the FUSE_WRITE command from userspace causes the fuse\nserver to call the AIO completion function. The completion puts the\nstruct file, queuing a delayed fput to the fuse server task. When the\nfuse server task returns to userspace, it has to run the delayed fput,\nwhich in the case of a fuseblk server, it does synchronously.\n\nSending the FUSE_RELEASE command sychronously from fuse server threads\nis a bad idea because a client program can initiate enough simultaneous\nAIOs such that all the fuse server threads end up in delayed_fput, and\nnow there aren\u0026apos;t any threads left to handle the queued fuse commands.\n\nFix this by only using asynchronous fputs when closing files, and leave\na comment explaining why.(CVE-2025-40220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/notify: call exportfs_encode_fid with s_umount\n\nCalling intotify_show_fdinfo() on fd watching an overlayfs inode, while\nthe overlayfs is being unmounted, can lead to dereferencing NULL ptr.\n\nThis issue was found by syzkaller.\n\nRace Condition Diagram:\n\nThread 1 Thread 2\n-------- --------\n\ngeneric_shutdown_super()\n shrink_dcache_for_umount\n sb-\u0026gt;s_root = NULL\n\n |\n | vfs_read()\n | inotify_fdinfo()\n | * inode get from mark *\n | show_mark_fhandle(m, inode)\n | exportfs_encode_fid(inode, ..)\n | ovl_encode_fh(inode, ..)\n | ovl_check_encode_origin(inode)\n | * deref i_sb-\u0026gt;s_root *\n |\n |\n v\n fsnotify_sb_delete(sb)\n\nWhich then leads to:\n\n[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)\n\n\u0026lt;snip registers, unreliable trace\u0026gt;\n\n[ 32.143353] Call Trace:\n[ 32.143732] ovl_encode_fh+0xd5/0x170\n[ 32.144031] exportfs_encode_inode_fh+0x12f/0x300\n[ 32.144425] show_mark_fhandle+0xbe/0x1f0\n[ 32.145805] inotify_fdinfo+0x226/0x2d0\n[ 32.146442] inotify_show_fdinfo+0x1c5/0x350\n[ 32.147168] seq_show+0x530/0x6f0\n[ 32.147449] seq_read_iter+0x503/0x12a0\n[ 32.148419] seq_read+0x31f/0x410\n[ 32.150714] vfs_read+0x1f0/0x9e0\n[ 32.152297] ksys_read+0x125/0x240\n\nIOW ovl_check_encode_origin derefs inode-\u0026gt;i_sb-\u0026gt;s_root, after it was set\nto NULL in the unmount path.\n\nFix it by protecting calling exportfs_encode_fid() from\nshow_mark_fhandle() with s_umount lock.\n\nThis form of fix was suggested by Amir in [1].\n\n[1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/(CVE-2025-40237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix unlikely race in gdlm_put_lock\n\nIn gdlm_put_lock(), there is a small window of time in which the\nDFL_UNMOUNT flag has been set but the lockspace hasn\u0026apos;t been released,\nyet. In that window, dlm may still call gdlm_ast() and gdlm_bast().\nTo prevent it from dereferencing freed glock objects, only free the\nglock if the lockspace has actually been released.(CVE-2025-40242)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndevlink: rate: Unset parent pointer in devl_rate_nodes_destroy\n\nThe function devl_rate_nodes_destroy is documented to \u0026quot;Unset parent for\nall rate objects\u0026quot;. However, it was only calling the driver-specific\n`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing\nthe parent\u0026apos;s refcount, without actually setting the\n`devlink_rate-\u0026gt;parent` pointer to NULL.\n\nThis leaves a dangling pointer in the `devlink_rate` struct, which cause\nrefcount error in netdevsim[1] and mlx5[2]. In addition, this is\ninconsistent with the behavior of `devlink_nl_rate_parent_node_set`,\nwhere the parent pointer is correctly cleared.\n\nThis patch fixes the issue by explicitly setting `devlink_rate-\u0026gt;parent`\nto NULL after notifying the driver, thus fulfilling the function\u0026apos;s\ndocumented behavior for all rate objects.\n\n[1]\nrepro steps:\necho 1 \u0026gt; /sys/bus/netdevsim/new_device\ndevlink dev eswitch set netdevsim/netdevsim1 mode switchdev\necho 1 \u0026gt; /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs\ndevlink port function rate add netdevsim/netdevsim1/test_node\ndevlink port function rate set netdevsim/netdevsim1/128 parent test_node\necho 1 \u0026gt; /sys/bus/netdevsim/del_device\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n devl_rate_leaf_destroy+0x8d/0x90\n __nsim_dev_port_del+0x6c/0x70 [netdevsim]\n nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]\n nsim_drv_remove+0x2b/0xb0 [netdevsim]\n device_release_driver_internal+0x194/0x1f0\n bus_remove_device+0xc6/0x130\n device_del+0x159/0x3c0\n device_unregister+0x1a/0x60\n del_device_store+0x111/0x170 [netdevsim]\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x55/0x10f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\ndevlink dev eswitch set pci/0000:08:00.0 mode switchdev\ndevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000\ndevlink port function rate add pci/0000:08:00.0/group1\ndevlink port function rate set pci/0000:08:00.0/32768 parent group1\nmodprobe -r mlx5_ib mlx5_fwctl mlx5_core\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n devl_rate_leaf_destroy+0x8d/0x90\n mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]\n mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]\n mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]\n mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]\n notifier_call_chain+0x33/0xa0\n blocking_notifier_call_chain+0x3b/0x50\n mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]\n mlx5_eswitch_disable+0x63/0x90 [mlx5_core]\n mlx5_unload+0x1d/0x170 [mlx5_core]\n mlx5_uninit_one+0xa2/0x130 [mlx5_core]\n remove_one+0x78/0xd0 [mlx5_core]\n pci_device_remove+0x39/0xa0\n device_release_driver_internal+0x194/0x1f0\n unbind_store+0x99/0xa0\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x53/0x1f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-40251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u0026gt;dev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026amp;proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026amp;proc_subdir_lock);\n [time window] | rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n | write_unlock(\u0026amp;proc_subdir_lock);\n read_lock(\u0026amp;proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)(CVE-2025-40271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/secretmem: fix use-after-free race in fault handler\n\nWhen a page fault occurs in a secret memory file created with\n`memfd_secret(2)`, the kernel will allocate a new folio for it, mark the\nunderlying page as not-present in the direct map, and add it to the file\nmapping.\n\nIf two tasks cause a fault in the same page concurrently, both could end\nup allocating a folio and removing the page from the direct map, but only\none would succeed in adding the folio to the file mapping. The task that\nfailed undoes the effects of its attempt by (a) freeing the folio again\nand (b) putting the page back into the direct map. However, by doing\nthese two operations in this order, the page becomes available to the\nallocator again before it is placed back in the direct mapping.\n\nIf another task attempts to allocate the page between (a) and (b), and the\nkernel tries to access it via the direct map, it would result in a\nsupervisor not-present page fault.\n\nFix the ordering to restore the direct map before the folio is freed.(CVE-2025-40272)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE\n\nThis data originates from userspace and is used in buffer offset\ncalculations which could potentially overflow causing an out-of-bounds\naccess.(CVE-2025-40277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()\n\nIn the parse_adv_monitor_pattern() function, the value of\nthe \u0026apos;length\u0026apos; variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251).\nThe size of the \u0026apos;value\u0026apos; array in the mgmt_adv_pattern structure is 31.\nIf the value of \u0026apos;pattern[i].length\u0026apos; is set in the user space\nand exceeds 31, the \u0026apos;patterns[i].value\u0026apos; array can be accessed\nout of bound when copied.\n\nIncreasing the size of the \u0026apos;value\u0026apos; array in\nthe \u0026apos;mgmt_adv_pattern\u0026apos; structure will break the userspace.\nConsidering this, and to avoid OOB access revert the limits for \u0026apos;offset\u0026apos;\nand \u0026apos;length\u0026apos; back to the value of HCI_MAX_AD_LENGTH.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with SVACE.(CVE-2025-40294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: validate skb length for unknown CC opcode\n\nIn hci_cmd_complete_evt(), if the command complete event has an unknown\nopcode, we assume the first byte of the remaining skb-\u0026gt;data contains the\nreturn status. However, parameter data has previously been pulled in\nhci_event_func(), which may leave the skb empty. If so, using skb-\u0026gt;data[0]\nfor the return status uses un-init memory.\n\nThe fix is to check skb-\u0026gt;len before using skb-\u0026gt;data.(CVE-2025-40301)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bcsp: receive data only if registered\n\nCurrently, bcsp_recv() can be called even when the BCSP protocol has not\nbeen registered. This leads to a NULL pointer dereference, as shown in\nthe following stack trace:\n\n KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]\n RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590\n Call Trace:\n \u0026lt;TASK\u0026gt;\n hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627\n tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290\n tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nTo prevent this, ensure that the HCI_UART_REGISTERED flag is set before\nprocessing received data. If the protocol is not registered, return\n-EUNATCH.(CVE-2025-40308)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once\n\nhci_cmd_sync_dequeue_once() does lookup and then cancel\nthe entry under two separate lock sections. Meanwhile,\nhci_cmd_sync_work() can also delete the same entry,\nleading to double list_del() and \u0026quot;UAF\u0026quot;.\n\nFix this by holding cmd_sync_work_lock across both\nlookup and cancel, so that the entry cannot be removed\nconcurrently.(CVE-2025-40318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Don\u0026apos;t leak robust_list pointer on exec race\n\nsys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()\nto check if the calling task is allowed to access another task\u0026apos;s\nrobust_list pointer. This check is racy against a concurrent exec() in the\ntarget process.\n\nDuring exec(), a task may transition from a non-privileged binary to a\nprivileged one (e.g., setuid binary) and its credentials/memory mappings\nmay change. If get_robust_list() performs ptrace_may_access() before\nthis transition, it may erroneously allow access to sensitive information\nafter the target becomes privileged.\n\nA racy access allows an attacker to exploit a window during which\nptrace_may_access() passes before a target process transitions to a\nprivileged state via exec().\n\nFor example, consider a non-privileged task T that is about to execute a\nsetuid-root binary. An attacker task A calls get_robust_list(T) while T\nis still unprivileged. Since ptrace_may_access() checks permissions\nbased on current credentials, it succeeds. However, if T begins exec\nimmediately afterwards, it becomes privileged and may change its memory\nmappings. Because get_robust_list() proceeds to access T-\u0026gt;robust_list\nwithout synchronizing with exec() it may read user-space pointers from a\nnow-privileged process.\n\nThis violates the intended post-exec access restrictions and could\nexpose sensitive memory addresses or be used as a primitive in a larger\nexploit chain. Consequently, the race can lead to unauthorized\ndisclosure of information across privilege boundaries and poses a\npotential security risk.\n\nTake a read lock on signal-\u0026gt;exec_update_lock prior to invoking\nptrace_may_access() and accessing the robust_list/compat_robust_list.\nThis ensures that the target task\u0026apos;s exec state remains stable during the\ncheck, allowing for consistent and synchronized validation of\ncredentials.(CVE-2025-40341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: use lock accessing port_state and rport state\n\nnvme_fc_unregister_remote removes the remote port on a lport object at\nany point in time when there is no active association. This races with\nwith the reconnect logic, because nvme_fc_create_association is not\ntaking a lock to check the port_state and atomically increase the\nactive count on the rport.(CVE-2025-40342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-fc: avoid scheduling association deletion twice\n\nWhen forcefully shutting down a port via the configfs interface,\nnvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and\nthen nvmet_disable_port(). Both functions will eventually schedule all\nremaining associations for deletion.\n\nThe current implementation checks whether an association is about to be\nremoved, but only after the work item has already been scheduled. As a\nresult, it is possible for the first scheduled work item to free all\nresources, and then for the same work item to be scheduled again for\ndeletion.\n\nBecause the association list is an RCU list, it is not possible to take\na lock and remove the list entry directly, so it cannot be looked up\nagain. Instead, a flag (terminating) must be used to determine whether\nthe association is already in the process of being deleted.(CVE-2025-40343)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Fix incorrect error check in topology_parse_cpu_capacity()\n\nFix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()\nwhich causes the code to proceed with NULL clock pointers. The current\nlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both\nvalid pointers and NULL, leading to potential NULL pointer dereference\nin clk_get_rate().\n\nPer include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:\n\u0026quot;The error code within @ptr if it is an error pointer; 0 otherwise.\u0026quot;\n\nThis means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL\npointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)\nwhen cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be\ncalled when of_clk_get() returns NULL.\n\nReplace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid\npointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()\n\nThe syzbot reported issue in hfsplus_delete_cat():\n\n[ 70.682285][ T9333] =====================================================\n[ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220\n[ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220\n[ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0\n[ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310\n[ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810\n[ 70.685447][ T9333] do_rmdir+0x964/0xea0\n[ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0\n[ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0\n[ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.687646][ T9333]\n[ 70.687856][ T9333] Uninit was stored to memory at:\n[ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0\n[ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800\n[ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600\n[ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70\n[ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0\n[ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30\n[ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0\n[ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0\n[ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.692773][ T9333]\n[ 70.692990][ T9333] Uninit was stored to memory at:\n[ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0\n[ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800\n[ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700\n[ 70.694911][ T9333] mount_bdev+0x37b/0x530\n[ 70.695320][ T9333] hfsplus_mount+0x4d/0x60\n[ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0\n[ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0\n[ 70.696588][ T9333] do_new_mount+0x73e/0x1630\n[ 70.697013][ T9333] path_mount+0x6e3/0x1eb0\n[ 70.697425][ T9333] __se_sys_mount+0x733/0x830\n[ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150\n[ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0\n[ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.699730][ T9333]\n[ 70.699946][ T9333] Uninit was created at:\n[ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60\n[ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0\n[ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0\n[ 70.701774][ T9333] allocate_slab+0x30e/0x1390\n[ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0\n[ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20\n[ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0\n[ 70.703598][ T9333] alloc_inode+0x82/0x490\n[ 70.703984][ T9333] iget_locked+0x22e/0x1320\n[ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0\n[ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0\n[ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700\n[ 70.705776][ T9333] mount_bdev+0x37b/0x530\n[ 70.706171][ T9333] hfsplus_mount+0x4d/0x60\n[ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0\n[ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0\n[ 70.707444][ T9333] do_new_mount+0x73e/0x1630\n[ 70.707865][ T9333] path_mount+0x6e3/0x1eb0\n[ 70.708270][ T9333] __se_sys_mount+0x733/0x830\n[ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150\n[ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0\n[ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.710611][ T9333]\n[ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17\n[ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 70.712490][ T9333] =====================================================\n[ 70.713085][ T9333] Disabling lock debugging due to kernel taint\n[ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...\n[ 70.714159][ T9333] \n---truncated---(CVE-2025-40351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: stacktrace: Disable KASAN checks for non-current tasks\n\nUnwinding the stack of a task other than current, KASAN would report\n\u0026quot;BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460\u0026quot;\n\nThere is a same issue on x86 and has been resolved by the commit\n84936118bdf3 (\u0026quot;x86/unwind: Disable KASAN checks for non-current tasks\u0026quot;)\nThe solution could be applied to RISC-V too.\n\nThis patch also can solve the issue:\nhttps://seclists.org/oss-sec/2025/q4/23\n\n[(CVE-2025-40358)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: Fix KASAN global-out-of-bounds warning\n\nWhen running \u0026quot;perf mem record\u0026quot; command on CWF, the below KASAN\nglobal-out-of-bounds warning is seen.\n\n ==================================================================\n BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0\n Read of size 4 at addr ffffffffb721d000 by task dtlb/9850\n\n Call Trace:\n\n kasan_report+0xb8/0xf0\n cmt_latency_data+0x176/0x1b0\n setup_arch_pebs_sample_data+0xf49/0x2560\n intel_pmu_drain_arch_pebs+0x577/0xb00\n handle_pmi_common+0x6c4/0xc80\n\nThe issue is caused by below code in __grt_latency_data(). The code\ntries to access x86_hybrid_pmu structure which doesn\u0026apos;t exist on\nnon-hybrid platform like CWF.\n\n WARN_ON_ONCE(hybrid_pmu(event-\u0026gt;pmu)-\u0026gt;pmu_type == hybrid_big)\n\nSo add is_hybrid() check before calling this WARN_ON_ONCE to fix the\nglobal-out-of-bounds access issue.(CVE-2025-40359)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-40361)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Ensure XFD state on signal delivery\n\nSean reported [1] the following splat when running KVM tests:\n\n WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70\n Call Trace:\n \u0026lt;TASK\u0026gt;\n fpu__clear_user_states+0x9c/0x100\n arch_do_signal_or_restart+0x142/0x210\n exit_to_user_mode_loop+0x55/0x100\n do_syscall_64+0x205/0x2c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nChao further identified [2] a reproducible scenario involving signal\ndelivery: a non-AMX task is preempted by an AMX-enabled task which\nmodifies the XFD MSR.\n\nWhen the non-AMX task resumes and reloads XSTATE with init values,\na warning is triggered due to a mismatch between fpstate::xfd and the\nCPU\u0026apos;s current XFD state. fpu__clear_user_states() does not currently\nre-synchronize the XFD state after such preemption.\n\nInvoke xfd_update_state() which detects and corrects the mismatch if\nthere is a dynamic feature.\n\nThis also benefits the sigreturn path, as fpu__restore_sig() may call\nfpu__clear_user_states() when the sigframe is inaccessible.\n\n[ dhansen: minor changelog munging ](CVE-2025-68171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix softlockup in ftrace_module_enable\n\nA soft lockup was observed when loading amdgpu module.\nIf a module has a lot of tracable functions, multiple calls\nto kallsyms_lookup can spend too much time in RCU critical\nsection and with disabled preemption, causing kernel panic.\nThis is the same issue that was fixed in\ncommit d0b24b4e91fc (\u0026quot;ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY\nkernels\u0026quot;) and commit 42ea22e754ba (\u0026quot;ftrace: Add cond_resched() to\nftrace_graph_set_hash()\u0026quot;).\n\nFix it the same way by adding cond_resched() in ftrace_module_enable.(CVE-2025-68173)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\namd/amdkfd: enhance kfd process check in switch partition\n\ncurrent switch partition only check if kfd_processes_table is empty.\nkfd_prcesses_table entry is deleted in kfd_process_notifier_release, but\nkfd_process tear down is in kfd_process_wq_release.\n\nconsider two processes:\n\nProcess A (workqueue) -\u0026gt; kfd_process_wq_release -\u0026gt; Access kfd_node member\nProcess B switch partition -\u0026gt; amdgpu_xcp_pre_partition_switch -\u0026gt; amdgpu_amdkfd_device_fini_sw\n-\u0026gt; kfd_node tear down.\n\nProcess A and B may trigger a race as shown in dmesg log.\n\nThis patch is to resolve the race by adding an atomic kfd_process counter\nkfd_processes_count, it increment as create kfd process, decrement as\nfinish kfd_process_wq_release.\n\nv2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds\nand bug fix. (Philip Yang)\n\n[3966658.307702] divide error: 0000 [#1] SMP NOPTI\n[3966658.350818] i10nm_edac\n[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted\n[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]\n[3966658.362839] nfit\n[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu]\n[3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 \u0026lt;f7\u0026gt; be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00\n[3966658.380967] x86_pkg_temp_thermal\n[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246\n[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000\n[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00\n[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4\n[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000\n[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800\n[3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000\n[3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0\n[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[3966658.391536] PKRU: 55555554\n[3966658.391536] Call Trace:\n[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu]\n[3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu]\n[3966658.399754] intel_powerclamp\n[3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu]\n[3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu]\n[3966658.410516] coretemp\n[3966658.434016] process_one_work+0x1ad/0x380\n[3966658.434021] worker_thread+0x49/0x310\n[3966658.438963] kvm_intel\n[3966658.446041] ? process_one_work+0x380/0x380\n[3966658.446045] kthread+0x118/0x140\n[3966658.446047] ? __kthread_bind_mask+0x60/0x60\n[3966658.446050] ret_from_fork+0x1f/0x30\n[3966658.446053] Modules linked in: kpatch_20765354(OEK)\n[3966658.455310] kvm\n[3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)\n[3966658.473462] idxd_mdev\n[3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo\n---truncated---(CVE-2025-68174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: cadence: Check for the existence of cdns_pcie::ops before using it\n\ncdns_pcie::ops might not be populated by all the Cadence glue drivers. This\nis going to be true for the upcoming Sophgo platform which doesn\u0026apos;t set the\nops.\n\nHence, add a check to prevent NULL pointer dereference.\n\n[mani: reworded subject and description](CVE-2025-68176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()\n\nUse RCU to avoid a pair of atomic operations and a potential\nUAF on dst_dev()-\u0026gt;flags.(CVE-2025-68188)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Add bpf_prog_run_data_pointers()\n\nsyzbot found that cls_bpf_classify() is able to change\ntc_skb_cb(skb)-\u0026gt;drop_reason triggering a warning in sk_skb_reason_drop().\n\nWARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]\nWARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214\n\nstruct tc_skb_cb has been added in commit ec624fe740b4 (\u0026quot;net/sched:\nExtend qdisc control block with tc control block\u0026quot;), which added a wrong\ninteraction with db58ba459202 (\u0026quot;bpf: wire in data and data_end for\ncls_act_bpf\u0026quot;).\n\ndrop_reason was added later.\n\nAdd bpf_prog_run_data_pointers() helper to save/restore the net_sched\nstorage colliding with BPF data_meta/data_end.(CVE-2025-68200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: add seqadj extension for natted connections\n\nSequence adjustment may be required for FTP traffic with PASV/EPSV modes.\ndue to need to re-write packet payload (IP, port) on the ftp control\nconnection. This can require changes to the TCP length and expected\nseq / ack_seq.\n\nThe easiest way to reproduce this issue is with PASV mode.\nExample ruleset:\ntable inet ftp_nat {\n ct helper ftp_helper {\n type \u0026quot;ftp\u0026quot; protocol tcp\n l3proto inet\n }\n\n chain prerouting {\n type filter hook prerouting priority 0; policy accept;\n tcp dport 21 ct state new ct helper set \u0026quot;ftp_helper\u0026quot;\n }\n}\ntable ip nat {\n chain prerouting {\n type nat hook prerouting priority -100; policy accept;\n tcp dport 21 dnat ip prefix to ip daddr map {\n\t\t\t192.168.100.1 : 192.168.13.2/32 }\n }\n\n chain postrouting {\n type nat hook postrouting priority 100 ; policy accept;\n tcp sport 21 snat ip prefix to ip saddr map {\n\t\t\t192.168.13.2 : 192.168.100.1/32 }\n }\n}\n\nNote that the ftp helper gets assigned *after* the dnat setup.\n\nThe inverse (nat after helper assign) is handled by an existing\ncheck in nf_nat_setup_info() and will not show the problem.\n\nTopoloy:\n\n +-------------------+ +----------------------------------+\n | FTP: 192.168.13.2 | \u0026lt;-\u0026gt; | NAT: 192.168.13.3, 192.168.100.1 |\n +-------------------+ +----------------------------------+\n |\n +-----------------------+\n | Client: 192.168.100.2 |\n +-----------------------+\n\nftp nat changes do not work as expected in this case:\nConnected to 192.168.100.1.\n[..]\nftp\u0026gt; epsv\nEPSV/EPRT on IPv4 off.\nftp\u0026gt; ls\n227 Entering passive mode (192,168,100,1,209,129).\n421 Service not available, remote server has closed connection.\n\nKernel logs:\nMissing nfct_seqadj_ext_add() setup call\nWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41\n[..]\n __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat]\n nf_nat_ftp+0x142/0x280 [nf_nat_ftp]\n help+0x4d1/0x880 [nf_conntrack_ftp]\n nf_confirm+0x122/0x2e0 [nf_conntrack]\n nf_hook_slow+0x3c/0xb0\n ..\n\nFix this by adding the required extension when a conntrack helper is assigned\nto a connection that has a nat binding.(CVE-2025-68206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: account for current allocated stack depth in widen_imprecise_scalars()\n\nThe usage pattern for widen_imprecise_scalars() looks as follows:\n\n prev_st = find_prev_entry(env, ...);\n queued_st = push_stack(...);\n widen_imprecise_scalars(env, prev_st, queued_st);\n\nWhere prev_st is an ancestor of the queued_st in the explored states\ntree. This ancestor is not guaranteed to have same allocated stack\ndepth as queued_st. E.g. in the following case:\n\n def main():\n for i in 1..2:\n foo(i) // same callsite, differnt param\n\n def foo(i):\n if i == 1:\n use 128 bytes of stack\n iterator based loop\n\nHere, for a second \u0026apos;foo\u0026apos; call prev_st-\u0026gt;allocated_stack is 128,\nwhile queued_st-\u0026gt;allocated_stack is much smaller.\nwiden_imprecise_scalars() needs to take this into account and avoid\naccessing bpf_verifier_state-\u0026gt;frame[*]-\u0026gt;stack out of bounds.(CVE-2025-68208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntimers: Fix NULL function pointer race in timer_shutdown_sync()\n\nThere is a race condition between timer_shutdown_sync() and timer\nexpiration that can lead to hitting a WARN_ON in expire_timers().\n\nThe issue occurs when timer_shutdown_sync() clears the timer function\nto NULL while the timer is still running on another CPU. The race\nscenario looks like this:\n\nCPU0\t\t\t\t\tCPU1\n\t\t\t\t\t\u0026lt;SOFTIRQ\u0026gt;\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tbase-\u0026gt;running_timer = timer;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t[call_timer_fn enter]\n\t\t\t\t\tmod_timer()\n\t\t\t\t\t...\ntimer_shutdown_sync()\nlock_timer_base()\n// For now, will not detach the timer but only clear its function to NULL\nif (base-\u0026gt;running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer-\u0026gt;function = NULL;\nunlock_timer_base()\n\t\t\t\t\t[call_timer_fn exit]\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\tbase-\u0026gt;running_timer = NULL;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t...\n\t\t\t\t\t// Now timer is pending while its function set to NULL.\n\t\t\t\t\t// next timer trigger\n\t\t\t\t\t\u0026lt;SOFTIRQ\u0026gt;\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tWARN_ON_ONCE(!fn) // hit\n\t\t\t\t\t...\nlock_timer_base()\n// Now timer will detach\nif (base-\u0026gt;running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer-\u0026gt;function = NULL;\nunlock_timer_base()\n\nThe problem is that timer_shutdown_sync() clears the timer function\nregardless of whether the timer is currently running. This can leave a\npending timer with a NULL function pointer, which triggers the\nWARN_ON_ONCE(!fn) check in expire_timers().\n\nFix this by only clearing the timer function when actually detaching the\ntimer. If the timer is running, leave the function pointer intact, which is\nsafe because the timer will be properly detached when it finishes running.(CVE-2025-68214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot\n\nnvkm_falcon_fw::boot is allocated, but no one frees it. This causes a\nkmemleak warning.\n\nMake sure this data is deallocated.(CVE-2025-68235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Don\u0026apos;t skip unrelated instruction if INT3/INTO is replaced\n\nWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTn\ninstruction, discard the exception and retry the instruction if the code\nstream is changed (e.g. by a different vCPU) between when the CPU\nexecutes the instruction and when KVM decodes the instruction to get the\nnext RIP.\n\nAs effectively predicted by commit 6ef88d6e36c2 (\u0026quot;KVM: SVM: Re-inject\nINT3/INTO instead of retrying the instruction\u0026quot;), failure to verify that\nthe correct INTn instruction was decoded can effectively clobber guest\nstate due to decoding the wrong instruction and thus specifying the\nwrong next RIP.\n\nThe bug most often manifests as \u0026quot;Oops: int3\u0026quot; panics on static branch\nchecks in Linux guests. Enabling or disabling a static branch in Linux\nuses the kernel\u0026apos;s \u0026quot;text poke\u0026quot; code patching mechanism. To modify code\nwhile other CPUs may be executing that code, Linux (temporarily)\nreplaces the first byte of the original instruction with an int3 (opcode\n0xcc), then patches in the new code stream except for the first byte,\nand finally replaces the int3 with the first byte of the new code\nstream. If a CPU hits the int3, i.e. executes the code while it\u0026apos;s being\nmodified, then the guest kernel must look up the RIP to determine how to\nhandle the #BP, e.g. by emulating the new instruction. If the RIP is\nincorrect, then this lookup fails and the guest kernel panics.\n\nThe bug reproduces almost instantly by hacking the guest kernel to\nrepeatedly check a static branch[1] while running a drgn script[2] on\nthe host to constantly swap out the memory containing the guest\u0026apos;s TSS.\n\n[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a\n[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b(CVE-2025-68259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: add i_data_sem protection in ext4_destroy_inline_data_nolock()\n\nFix a race between inline data destruction and block mapping.\n\nThe function ext4_destroy_inline_data_nolock() changes the inode data\nlayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.\nAt the same time, another thread may execute ext4_map_blocks(), which\ntests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()\nor ext4_ind_map_blocks().\n\nWithout i_data_sem protection, ext4_ind_map_blocks() may receive inode\nwith EXT4_INODE_EXTENTS flag and triggering assert.\n\nkernel BUG at fs/ext4/indirect.c:546!\nEXT4-fs (loop2): unmounting filesystem.\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681\n _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822\n ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124\n ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255\n ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000\n generic_perform_write+0x259/0x5d0 mm/filemap.c:3846\n ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285\n ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679\n call_write_iter include/linux/fs.h:2271 [inline]\n do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735\n do_iter_write+0x186/0x710 fs/read_write.c:861\n vfs_iter_write+0x70/0xa0 fs/read_write.c:902\n iter_file_splice_write+0x73b/0xc90 fs/splice.c:685\n do_splice_from fs/splice.c:763 [inline]\n direct_splice_actor+0x10f/0x170 fs/splice.c:950\n splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896\n do_splice_direct+0x1a9/0x280 fs/splice.c:1002\n do_sendfile+0xb13/0x12c0 fs/read_write.c:1255\n __do_sys_sendfile64 fs/read_write.c:1323 [inline]\n __se_sys_sendfile64 fs/read_write.c:1309 [inline]\n __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2025-68261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: refresh inline data size before write operations\n\nThe cached ei-\u0026gt;i_inline_size can become stale between the initial size\ncheck and when ext4_update_inline_data()/ext4_create_inline_data() use\nit. Although ext4_get_max_inline_size() reads the correct value at the\ntime of the check, concurrent xattr operations can modify i_inline_size\nbefore ext4_write_lock_xattr() is acquired.\n\nThis causes ext4_update_inline_data() and ext4_create_inline_data() to\nwork with stale capacity values, leading to a BUG_ON() crash in\next4_write_inline_data():\n\n kernel BUG at fs/ext4/inline.c:1331!\n BUG_ON(pos + len \u0026gt; EXT4_I(inode)-\u0026gt;i_inline_size);\n\nThe race window:\n1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)\n2. Size check passes for 50-byte write\n3. [Another thread adds xattr, i_inline_size changes to 40]\n4. ext4_write_lock_xattr() acquires lock\n5. ext4_update_inline_data() uses stale i_inline_size = 60\n6. Attempts to write 50 bytes but only 40 bytes actually available\n7. BUG_ON() triggers\n\nFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()\nimmediately after acquiring xattr_sem. This ensures ext4_update_inline_data()\nand ext4_create_inline_data() work with current values that are protected\nfrom concurrent modifications.\n\nThis is similar to commit a54c4613dac1 (\u0026quot;ext4: fix race writing to an\ninline_data file while its xattrs are changing\u0026quot;) which fixed i_inline_off\nstaleness. This patch addresses the related i_inline_size staleness issue.(CVE-2025-68264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix admin request_queue lifetime\n\nThe namespaces can access the controller\u0026apos;s admin request_queue, and\nstale references on the namespaces may exist after tearing down the\ncontroller. Ensure the admin request_queue is active by moving the\ncontroller\u0026apos;s \u0026apos;put\u0026apos; to after all controller references have been released\nto ensure no one is can access the request_queue. This fixes a reported\nuse-after-free bug:\n\n BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0\n Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287\n CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15\n Tainted: [E]=UNSIGNED_MODULE\n Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x4f/0x60\n print_report+0xc4/0x620\n ? _raw_spin_lock_irqsave+0x70/0xb0\n ? _raw_read_unlock_irqrestore+0x30/0x30\n ? blk_queue_enter+0x41c/0x4a0\n kasan_report+0xab/0xe0\n ? blk_queue_enter+0x41c/0x4a0\n blk_queue_enter+0x41c/0x4a0\n ? __irq_work_queue_local+0x75/0x1d0\n ? blk_queue_start_drain+0x70/0x70\n ? irq_work_queue+0x18/0x20\n ? vprintk_emit.part.0+0x1cc/0x350\n ? wake_up_klogd_work_func+0x60/0x60\n blk_mq_alloc_request+0x2b7/0x6b0\n ? __blk_mq_alloc_requests+0x1060/0x1060\n ? __switch_to+0x5b7/0x1060\n nvme_submit_user_cmd+0xa9/0x330\n nvme_user_cmd.isra.0+0x240/0x3f0\n ? force_sigsegv+0xe0/0xe0\n ? nvme_user_cmd64+0x400/0x400\n ? vfs_fileattr_set+0x9b0/0x9b0\n ? cgroup_update_frozen_flag+0x24/0x1c0\n ? cgroup_leave_frozen+0x204/0x330\n ? nvme_ioctl+0x7c/0x2c0\n blkdev_ioctl+0x1a8/0x4d0\n ? blkdev_common_ioctl+0x1930/0x1930\n ? fdget+0x54/0x380\n __x64_sys_ioctl+0x129/0x190\n do_syscall_64+0x5b/0x160\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f765f703b0b\n Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48\n RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b\n RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003\n RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000\n R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003\n R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60\n \u0026lt;/TASK\u0026gt;(CVE-2025-68265)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix crash in process_v2_sparse_read() for encrypted directories\n\nThe crash in process_v2_sparse_read() for fscrypt-encrypted directories\nhas been reported. Issue takes place for Ceph msgr2 protocol in secure\nmode. It can be reproduced by the steps:\n\nsudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure\n\n(1) mkdir /mnt/cephfs/fscrypt-test-3\n(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3\n(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3\n(4) fscrypt lock /mnt/cephfs/fscrypt-test-3\n(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3\n(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar\n(7) Issue has been triggered\n\n[ 408.072247] ------------[ cut here ]------------\n[ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865\nceph_con_v2_try_read+0x4b39/0x72f0\n[ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common\nintel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery\npmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass\npolyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse\nserio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg\npata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore\n[ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+\n[ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.17.0-5.fc42 04/01/2014\n[ 408.072310] Workqueue: ceph-msgr ceph_con_workfn\n[ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0\n[ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8\n8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff \u0026lt;0f\u0026gt; 0b e9 06\nfe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85\n[ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246\n[ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38\n[ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8\n[ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8\n[ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000\n[ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000)\nknlGS:0000000000000000\n[ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0\n[ 408.072336] PKRU: 55555554\n[ 408.072337] Call Trace:\n[ 408.072338] \u0026lt;TASK\u0026gt;\n[ 408.072340] ? sched_clock_noinstr+0x9/0x10\n[ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10\n[ 408.072347] ? _raw_spin_unlock+0xe/0x40\n[ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830\n[ 408.072353] ? __kasan_check_write+0x14/0x30\n[ 408.072357] ? mutex_lock+0x84/0xe0\n[ 408.072359] ? __pfx_mutex_lock+0x10/0x10\n[ 408.072361] ceph_con_workfn+0x27e/0x10e0\n[ 408.072364] ? metric_delayed_work+0x311/0x2c50\n[ 408.072367] process_one_work+0x611/0xe20\n[ 408.072371] ? __kasan_check_write+0x14/0x30\n[ 408.072373] worker_thread+0x7e3/0x1580\n[ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 408.072378] ? __pfx_worker_thread+0x10/0x10\n[ 408.072381] kthread+0x381/0x7a0\n[ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 408.072385] ? __pfx_kthread+0x10/0x10\n[ 408.072387] ? __kasan_check_write+0x14/0x30\n[ 408.072389] ? recalc_sigpending+0x160/0x220\n[ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50\n[ 408.072394] ? calculate_sigpending+0x78/0xb0\n[ 408.072395] ? __pfx_kthread+0x10/0x10\n[ 408.072397] ret_from_fork+0x2b6/0x380\n[ 408.072400] ? __pfx_kthread+0x10/0x10\n[ 408.072402] ret_from_fork_asm+0x1a/0x30\n[ 408.072406] \u0026lt;/TASK\u0026gt;\n[ 408.072407] ---[ end trace 0000000000000000 ]---\n[ 408.072418] Oops: general protection fault, probably for non-canonical\naddress 0xdffffc00000000\n---truncated---(CVE-2025-68297)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI/AER: Fix NULL pointer access by aer_info\n\nThe kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info-\u0026gt;xxx\nwill result in kernel panic. Fix it.(CVE-2025-68309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer\n\nWhen a UAS device is unplugged during data transfer, there is\na probability of a system panic occurring. The root cause is\nan access to an invalid memory address during URB callback handling.\nSpecifically, this happens when the dma_direct_unmap_sg() function\nis called within the usb_hcd_unmap_urb_for_dma() interface, but the\nsg-\u0026gt;dma_address field is 0 and the sg data structure has already been\nfreed.\n\nThe SCSI driver sends transfer commands by invoking uas_queuecommand_lck()\nin uas.c, using the uas_submit_urbs() function to submit requests to USB.\nWithin the uas_submit_urbs() implementation, three URBs (sense_urb,\ndata_urb, and cmd_urb) are sequentially submitted. Device removal may\noccur at any point during uas_submit_urbs execution, which may result\nin URB submission failure. However, some URBs might have been successfully\nsubmitted before the failure, and uas_submit_urbs will return the -ENODEV\nerror code in this case. The current error handling directly calls\nscsi_done(). In the SCSI driver, this eventually triggers scsi_complete()\nto invoke scsi_end_request() for releasing the sgtable. The successfully\nsubmitted URBs, when being unlinked to giveback, call\nusb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg\nunmapping operations since the sg data structure has already been freed.\n\nThis patch modifies the error condition check in the uas_submit_urbs()\nfunction. When a UAS device is removed but one or more URBs have already\nbeen successfully submitted to USB, it avoids immediately invoking\nscsi_done() and save the cmnd to devinfo-\u0026gt;cmnd array. If the successfully\nsubmitted URBs is completed before devinfo-\u0026gt;resetting being set, then\nthe scsi_done() function will be called within uas_try_complete() after\nall pending URB operations are finalized. Otherwise, the scsi_done()\nfunction will be called within uas_zap_pending(), which is executed after\nusb_kill_anchored_urbs().\n\nThe error handling only takes effect when uas_queuecommand_lck() calls\nuas_submit_urbs() and returns the error value -ENODEV . In this case,\nthe device is disconnected, and the flow proceeds to uas_disconnect(),\nwhere uas_zap_pending() is invoked to call uas_try_complete().(CVE-2025-68331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted\n\nThere\u0026apos;s issue when file system corrupted:\n------------[ cut here ]------------\nkernel BUG at fs/jbd2/transaction.c:1289!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next\nRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0\nRSP: 0018:ffff888117aafa30 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534\nRDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010\nRBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028\nR10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __ext4_journal_get_create_access+0x42/0x170\n ext4_getblk+0x319/0x6f0\n ext4_bread+0x11/0x100\n ext4_append+0x1e6/0x4a0\n ext4_init_new_dir+0x145/0x1d0\n ext4_mkdir+0x326/0x920\n vfs_mkdir+0x45c/0x740\n do_mkdirat+0x234/0x2f0\n __x64_sys_mkdir+0xd6/0x120\n do_syscall_64+0x5f/0xfa0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe above issue occurs with us in errors=continue mode when accompanied by\nstorage failures. There have been many inconsistencies in the file system\ndata.\nIn the case of file system data inconsistency, for example, if the block\nbitmap of a referenced block is not set, it can lead to the situation where\na block being committed is allocated and used again. As a result, the\nfollowing condition will not be satisfied then trigger BUG_ON. Of course,\nit is entirely possible to construct a problematic image that can trigger\nthis BUG_ON through specific operations. In fact, I have constructed such\nan image and easily reproduced this issue.\nTherefore, J_ASSERT() holds true only under ideal conditions, but it may\nnot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()\ndirectly in abnormal situations would cause the system to crash, which is\nclearly not what we want. So here we directly trigger a JBD abort instead\nof immediately invoking BUG_ON.(CVE-2025-68337)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid\n\nFixes a crash when layout is null during this call stack:\n\nwrite_inode\n -\u0026gt; nfs4_write_inode\n -\u0026gt; pnfs_layoutcommit_inode\n\npnfs_set_layoutcommit relies on the lseg refcount to keep the layout\naround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt\nto reference a null layout.(CVE-2025-68349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Protect regulator_supply_alias_list with regulator_list_mutex\n\nregulator_supply_alias_list was accessed without any locking in\nregulator_supply_alias(), regulator_register_supply_alias(), and\nregulator_unregister_supply_alias(). Concurrent registration,\nunregistration and lookups can race, leading to:\n\n1 use-after-free if an alias entry is removed while being read,\n2 duplicate entries when two threads register the same alias,\n3 inconsistent alias mappings observed by consumers.\n\nProtect all traversals, insertions and deletions on\nregulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Prevent recursive memory reclaim\n\nFunction new_inode() returns a new inode with inode-\u0026gt;i_mapping-\u0026gt;gfp_mask\nset to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so\nallocations in that address space can recurse into filesystem memory\nreclaim. We don\u0026apos;t want that to happen because it can consume a\nsignificant amount of stack memory.\n\nWorse than that is that it can also deadlock: for example, in several\nplaces, gfs2_unstuff_dinode() is called inside filesystem transactions.\nThis calls filemap_grab_folio(), which can allocate a new folio, which\ncan trigger memory reclaim. If memory reclaim recurses into the\nfilesystem and starts another transaction, a deadlock will ensue.\n\nTo fix these kinds of problems, prevent memory reclaim from recursing\ninto filesystem code by making sure that the gfp_mask of inode address\nspaces doesn\u0026apos;t include __GFP_FS.\n\nThe \u0026quot;meta\u0026quot; and resource group address spaces were already using GFP_NOFS\nas their gfp_mask (which doesn\u0026apos;t include __GFP_FS). The default value\nof GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To\navoid being overly limiting, use the default value and only knock off\nthe __GFP_FS flag. I\u0026apos;m not sure if this will actually make a\ndifference, but it also shouldn\u0026apos;t hurt.\n\nThis patch is loosely based on commit ad22c7a043c2 (\u0026quot;xfs: prevent stack\noverflows from page cache allocation\u0026quot;).\n\nFixes xfstest generic/273.(CVE-2025-68356)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()\n\nThe rtl8187_rx_cb() calculates the rx descriptor header address\nby subtracting its size from the skb tail pointer.\nHowever, it does not validate if the received packet\n(skb-\u0026gt;len from urb-\u0026gt;actual_length) is large enough to contain this\nheader.\n\nIf a truncated packet is received, this will lead to a buffer\nunderflow, reading memory before the start of the skb data area,\nand causing a kernel panic.\n\nAdd length checks for both rtl8187 and rtl8187b descriptor headers\nbefore attempting to access them, dropping the packet cleanly if the\ncheck fails.(CVE-2025-68362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check skb-\u0026gt;transport_header is set in bpf_skb_check_mtu\n\nThe bpf_skb_check_mtu helper needs to use skb-\u0026gt;transport_header when\nthe BPF_MTU_CHK_SEGS flag is used:\n\n\tbpf_skb_check_mtu(skb, ifindex, \u0026amp;mtu_len, 0, BPF_MTU_CHK_SEGS)\n\nThe transport_header is not always set. There is a WARN_ON_ONCE\nreport when CONFIG_DEBUG_NET is enabled + skb-\u0026gt;gso_size is set +\nbpf_prog_test_run is used:\n\nWARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071\n skb_gso_validate_network_len\n bpf_skb_check_mtu\n bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch\n bpf_test_run\n bpf_prog_test_run_skb\n\nFor a normal ingress skb (not test_run), skb_reset_transport_header\nis performed but there is plan to avoid setting it as described in\ncommit 2170a1f09148 (\u0026quot;net: no longer reset transport_header in __netif_receive_skb_core()\u0026quot;).\n\nThis patch fixes the bpf helper by checking\nskb_transport_header_was_set(). The check is done just before\nskb-\u0026gt;transport_header is used, to avoid breaking the existing bpf prog.\nThe WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.(CVE-2025-68363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: ETR: Fix ETR buffer use-after-free issue\n\nWhen ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed\nand enabled again, currently sysfs_buf will point to the newly\nallocated memory(buf_new) and free the old memory(buf_old). But the\netr_buf that is being used by the ETR remains pointed to buf_old, not\nupdated to buf_new. In this case, it will result in a memory\nuse-after-free issue.\n\nFix this by checking ETR\u0026apos;s mode before updating and releasing buf_old,\nif the mode is CS_MODE_SYSFS, then skip updating and releasing it.(CVE-2025-68376)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix stackmap overflow check in __bpf_get_stackid()\n\nSyzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()\nwhen copying stack trace data. The issue occurs when the perf trace\n contains more stack entries than the stack map bucket can hold,\n leading to an out-of-bounds write in the bucket\u0026apos;s data array.(CVE-2025-68378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id\n\nUse check_add_overflow() to guard against potential integer overflows\nwhen adding the binary blob lengths and the size of an asymmetric_key_id\nstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a\npossible buffer overflow when copying data from potentially malicious\nX.509 certificate fields that can be arbitrarily large, such as ASN.1\nINTEGER serial numbers, issuer names, etc.(CVE-2025-68724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Do not let BPF test infra emit invalid GSO types to stack\n\nYinhao et al. reported that their fuzzer tool was able to trigger a\nskb_warn_bad_offload() from netif_skb_features() -\u0026gt; gso_features_check().\nWhen a BPF program - triggered via BPF test infra - pushes the packet\nto the loopback device via bpf_clone_redirect() then mentioned offload\nwarning can be seen. GSO-related features are then rightfully disabled.\n\nWe get into this situation due to convert___skb_to_skb() setting\ngso_segs and gso_size but not gso_type. Technically, it makes sense\nthat this warning triggers since the GSO properties are malformed due\nto the gso_type. Potentially, the gso_type could be marked non-trustworthy\nthrough setting it at least to SKB_GSO_DODGY without any other specific\nassumptions, but that also feels wrong given we should not go further\ninto the GSO engine in the first place.\n\nThe checks were added in 121d57af308d (\u0026quot;gso: validate gso_type in GSO\nhandlers\u0026quot;) because there were malicious (syzbot) senders that combine\na protocol with a non-matching gso_type. If we would want to drop such\npackets, gso_features_check() currently only returns feature flags via\nnetif_skb_features(), so one location for potentially dropping such skbs\ncould be validate_xmit_unreadable_skb(), but then otoh it would be\nan additional check in the fast-path for a very corner case. Given\nbpf_clone_redirect() is the only place where BPF test infra could emit\nsuch packets, lets reject them right there.(CVE-2025-68725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()\n\nIn hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when\nsetup_instance() fails with an error code. Fix that by freeing the urb\nbefore freeing the hw structure. Also change the error paths to use the\ngoto ladder style.\n\nCompile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix improper freeing of purex item\n\nIn qla2xxx_process_purls_iocb(), an item is allocated via\nqla27xx_copy_multiple_pkt(), which internally calls\nqla24xx_alloc_purex_item().\n\nThe qla24xx_alloc_purex_item() function may return a pre-allocated item\nfrom a per-adapter pool for small allocations, instead of dynamically\nallocating memory with kzalloc().\n\nAn error handling path in qla2xxx_process_purls_iocb() incorrectly uses\nkfree() to release the item. If the item was from the pre-allocated\npool, calling kfree() on it is a bug that can lead to memory corruption.\n\nFix this by using the correct deallocation function,\nqla24xx_free_purex_item(), which properly handles both dynamically\nallocated and pre-allocated items.(CVE-2025-68741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Free special fields when update [lru_,]percpu_hash maps\n\nAs [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing\ncalls to \u0026apos;bpf_obj_free_fields()\u0026apos; in \u0026apos;pcpu_copy_value()\u0026apos; could cause the\nmemory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the\nmap gets freed.\n\nFix this by calling \u0026apos;bpf_obj_free_fields()\u0026apos; after\n\u0026apos;copy_map_value[,_long]()\u0026apos; in \u0026apos;pcpu_copy_value()\u0026apos;.(CVE-2025-68744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Clear cmds after chip reset\n\nCommit aefed3e5548f (\u0026quot;scsi: qla2xxx: target: Fix offline port handling\nand host reset handling\u0026quot;) caused two problems:\n\n1. Commands sent to FW, after chip reset got stuck and never freed as FW\n is not going to respond to them anymore.\n\n2. BUG_ON(cmd-\u0026gt;sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a\n (\u0026quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands\u0026quot;)\n attempted to fix this, but introduced another bug under different\n circumstances when two different CPUs were racing to call\n qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in\n dma_unmap_sg_attrs().\n\nSo revert \u0026quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands\u0026quot; and\npartially revert \u0026quot;scsi: qla2xxx: target: Fix offline port handling and\nhost reset handling\u0026quot; at __qla2x00_abort_all_cmds.(CVE-2025-68745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: Use RCU in blk_mq_[un]quiesce_tagset() instead of set-\u0026gt;tag_list_lock\n\nblk_mq_{add,del}_queue_tag_set() functions add and remove queues from\ntagset, the functions make sure that tagset and queues are marked as\nshared when two or more queues are attached to the same tagset.\nInitially a tagset starts as unshared and when the number of added\nqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared along\nwith all the queues attached to it. When the number of attached queues\ndrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and\nthe remaining queues as unshared.\n\nBoth functions need to freeze current queues in tagset before setting on\nunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions\nhold set-\u0026gt;tag_list_lock mutex, which makes sense as we do not want\nqueues to be added or deleted in the process. This used to work fine\nuntil commit 98d81f0df70c (\u0026quot;nvme: use blk_mq_[un]quiesce_tagset\u0026quot;)\nmade the nvme driver quiesce tagset instead of quiscing individual\nqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues in\nset-\u0026gt;tag_list while holding set-\u0026gt;tag_list_lock also.\n\nThis results in deadlock between two threads with these stacktraces:\n\n __schedule+0x47c/0xbb0\n ? timerqueue_add+0x66/0xb0\n schedule+0x1c/0xa0\n schedule_preempt_disabled+0xa/0x10\n __mutex_lock.constprop.0+0x271/0x600\n blk_mq_quiesce_tagset+0x25/0xc0\n nvme_dev_disable+0x9c/0x250\n nvme_timeout+0x1fc/0x520\n blk_mq_handle_expired+0x5c/0x90\n bt_iter+0x7e/0x90\n blk_mq_queue_tag_busy_iter+0x27e/0x550\n ? __blk_mq_complete_request_remote+0x10/0x10\n ? __blk_mq_complete_request_remote+0x10/0x10\n ? __call_rcu_common.constprop.0+0x1c0/0x210\n blk_mq_timeout_work+0x12d/0x170\n process_one_work+0x12e/0x2d0\n worker_thread+0x288/0x3a0\n ? rescuer_thread+0x480/0x480\n kthread+0xb8/0xe0\n ? kthread_park+0x80/0x80\n ret_from_fork+0x2d/0x50\n ? kthread_park+0x80/0x80\n ret_from_fork_asm+0x11/0x20\n\n __schedule+0x47c/0xbb0\n ? xas_find+0x161/0x1a0\n schedule+0x1c/0xa0\n blk_mq_freeze_queue_wait+0x3d/0x70\n ? destroy_sched_domains_rcu+0x30/0x30\n blk_mq_update_tag_set_shared+0x44/0x80\n blk_mq_exit_queue+0x141/0x150\n del_gendisk+0x25a/0x2d0\n nvme_ns_remove+0xc9/0x170\n nvme_remove_namespaces+0xc7/0x100\n nvme_remove+0x62/0x150\n pci_device_remove+0x23/0x60\n device_release_driver_internal+0x159/0x200\n unbind_store+0x99/0xa0\n kernfs_fop_write_iter+0x112/0x1e0\n vfs_write+0x2b1/0x3d0\n ksys_write+0x4e/0xb0\n do_syscall_64+0x5b/0x160\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe top stacktrace is showing nvme_timeout() called to handle nvme\ncommand timeout. timeout handler is trying to disable the controller and\nas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not\nto call queue callback handlers. The thread is stuck waiting for\nset-\u0026gt;tag_list_lock as it tries to walk the queues in set-\u0026gt;tag_list.\n\nThe lock is held by the second thread in the bottom stack which is\nwaiting for one of queues to be frozen. The queue usage counter will\ndrop to zero after nvme_timeout() finishes, and this will not happen\nbecause the thread will wait for this mutex forever.\n\nGiven that [un]quiescing queue is an operation that does not need to\nsleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking\nset-\u0026gt;tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU\nsafe list operations. Also, delete INIT_LIST_HEAD(\u0026amp;q-\u0026gt;tag_set_list)\nin blk_mq_del_queue_tag_set() because we can not re-initialize it while\nthe list is being traversed under RCU. The deleted queue will not be\nadded/deleted to/from a tagset and it will be freed in blk_free_queue()\nafter the end of RCU grace period.(CVE-2025-68756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: only set free_cpus for online runqueues\n\nCommit 16b269436b72 (\u0026quot;sched/deadline: Modify cpudl::free_cpus\nto reflect rd-\u0026gt;online\u0026quot;) introduced the cpudl_set/clear_freecpu\nfunctions to allow the cpu_dl::free_cpus mask to be manipulated\nby the deadline scheduler class rq_on/offline callbacks so the\nmask would also reflect this state.\n\nCommit 9659e1eeee28 (\u0026quot;sched/deadline: Remove cpu_active_mask\nfrom cpudl_find()\u0026quot;) removed the check of the cpu_active_mask to\nsave some processing on the premise that the cpudl::free_cpus\nmask already reflected the runqueue online state.\n\nUnfortunately, there are cases where it is possible for the\ncpudl_clear function to set the free_cpus bit for a CPU when the\ndeadline runqueue is offline. When this occurs while a CPU is\nconnected to the default root domain the flag may retain the bad\nstate after the CPU has been unplugged. Later, a different CPU\nthat is transitioning through the default root domain may push a\ndeadline task to the powered down CPU when cpudl_find sees its\nfree_cpus bit is set. If this happens the task will not have the\nopportunity to run.\n\nOne example is outlined here:\nhttps://lore.kernel.org/lkml/(CVE-2025-68780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Reset t_task_cdb pointer in error case\n\nIf allocation of cmd-\u0026gt;t_task_cdb fails, it remains NULL but is later\ndereferenced in the \u0026apos;err\u0026apos; path.\n\nIn case of error, reset NULL t_task_cdb value to point at the default\nfixed-size buffer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niomap: adjust read range correctly for non-block-aligned positions\n\niomap_adjust_read_range() assumes that the position and length passed in\nare block-aligned. This is not always the case however, as shown in the\nsyzbot generated case for erofs. This causes too many bytes to be\nskipped for uptodate blocks, which results in returning the incorrect\nposition and length to read in. If all the blocks are uptodate, this\nunderflows length and returns a position beyond the folio.\n\nFix the calculation to also take into account the block offset when\ncalculating how many bytes can be skipped for uptodate blocks.(CVE-2025-68794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: NFSv4 file creation neglects setting ACL\n\nAn NFSv4 client that sets an ACL with a named principal during file\ncreation retrieves the ACL afterwards, and finds that it is only a\ndefault ACL (based on the mode bits) and not the ACL that was\nrequested during file creation. This violates RFC 8881 section\n6.4.1.3: \u0026quot;the ACL attribute is set as given\u0026quot;.\n\nThe issue occurs in nfsd_create_setattr(), which calls\nnfsd_attrs_valid() to determine whether to call nfsd_setattr().\nHowever, nfsd_attrs_valid() checks only for iattr changes and\nsecurity labels, but not POSIX ACLs. When only an ACL is present,\nthe function returns false, nfsd_setattr() is skipped, and the\nPOSIX ACL is never applied to the inode.\n\nSubsequently, when the client retrieves the ACL, the server finds\nno POSIX ACL on the inode and returns one generated from the file\u0026apos;s\nmode bits rather than returning the originally-specified ACL.(CVE-2025-68803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix filename leak in __io_openat_prep()\n\n __io_openat_prep() allocates a struct filename using getname(). However,\nfor the condition of the file being installed in the fixed file table as\nwell as having O_CLOEXEC flag set, the function returns early. At that\npoint, the request doesn\u0026apos;t have REQ_F_NEED_CLEANUP flag set. Due to this,\nthe memory for the newly allocated struct filename is not cleaned up,\ncausing a memory leak.\n\nFix this by setting the REQ_F_NEED_CLEANUP for the request just after the\nsuccessful getname() call, so that when the request is torn down, the\nfilename will be cleaned up, along with other resources needing cleanup.(CVE-2025-68814)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: fw_tracer, Validate format string parameters\n\nAdd validation for format string parameters in the firmware tracer to\nprevent potential security vulnerabilities and crashes from malformed\nformat strings received from firmware.\n\nThe firmware tracer receives format strings from the device firmware and\nuses them to format trace messages. Without proper validation, bad\nfirmware could provide format strings with invalid format specifiers\n(e.g., %s, %p, %n) that could lead to crashes, or other undefined\nbehavior.\n\nAdd mlx5_tracer_validate_params() to validate that all format specifiers\nin trace strings are limited to safe integer/hex formats (%x, %d, %i,\n%u, %llx, %lx, etc.). Reject strings containing other format types that\ncould be used to access arbitrary memory or cause crashes.\nInvalid format strings are added to the trace output for visibility with\n\u0026quot;BAD_FORMAT: \u0026quot; prefix.(CVE-2025-68816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency\n\nUnder high concurrency, A tree-connection object (tcon) is freed on\na disconnect path while another path still holds a reference and later\nexecutes *_put()/write on it.(CVE-2025-68817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \u0026quot;scsi: qla2xxx: Perform lockless command completion in abort path\u0026quot;\n\nThis reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.\n\nThe commit being reverted added code to __qla2x00_abort_all_cmds() to\ncall sp-\u0026gt;done() without holding a spinlock. But unlike the older code\nbelow it, this new code failed to check sp-\u0026gt;cmd_type and just assumed\nTYPE_SRB, which results in a jump to an invalid pointer in target-mode\nwith TYPE_TGT_CMD:\n\nqla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success\n 0000000009f7a79b\nqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h\n mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.\nqla2xxx [0000:65:00.0]-d01e:8: -\u0026gt; fwdump no buffer\nqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event\n 0x8002 occurred\nqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -\n ha=0000000058183fda.\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPF: supervisor instruction fetch in kernel mode\nPF: error_code(0x0010) - not-present page\nPGD 0 P4D 0\nOops: 0010 [#1] SMP\nCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1\nHardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206\nRAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000\nRDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0\nRBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045\nR10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40\nR13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400\nFS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x4d/0x8b\n ? page_fault_oops+0x91/0x180\n ? trace_buffer_unlock_commit_regs+0x38/0x1a0\n ? exc_page_fault+0x391/0x5e0\n ? asm_exc_page_fault+0x22/0x30\n __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]\n qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]\n qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]\n qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]\n qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]\n kthread+0xa8/0xd0\n \u0026lt;/TASK\u0026gt;\n\nThen commit 4475afa2646d (\u0026quot;scsi: qla2xxx: Complete command early within\nlock\u0026quot;) added the spinlock back, because not having the lock caused a\nrace and a crash. But qla2x00_abort_srb() in the switch below already\nchecks for qla2x00_chip_is_down() and handles it the same way, so the\ncode above the switch is now redundant and still buggy in target-mode.\nRemove it.(CVE-2025-68818)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nshmem: fix recovery on rename failures\n\nmaple_tree insertions can fail if we are seriously short on memory;\nsimple_offset_rename() does not recover well if it runs into that.\nThe same goes for simple_offset_rename_exchange().\n\nMoreover, shmem_whiteout() expects that if it succeeds, the caller will\nprogress to d_move(), i.e. that shmem_rename2() won\u0026apos;t fail past the\nsuccessful call of shmem_whiteout().\n\nNot hard to fix, fortunately - mtree_store() can\u0026apos;t fail if the index we\nare trying to store into is already present in the tree as a singleton.\n\nFor simple_offset_rename_exchange() that\u0026apos;s enough - we just need to be\ncareful about the order of operations.\n\nFor simple_offset_rename() solution is to preinsert the target into the\ntree for new_dir; the rest can be done without any potentially failing\noperations.\n\nThat preinsertion has to be done in shmem_rename2() rather than in\nsimple_offset_rename() itself - otherwise we\u0026apos;d need to deal with the\npossibility of failure after successful shmem_whiteout().(CVE-2025-71072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Cap the number of PCR banks\n\ntpm2_get_pcr_allocation() does not cap any upper limit for the number of\nbanks. Cap the limit to eight banks so that out of bounds values coming\nfrom external I/O cause on only limited harm.(CVE-2025-71077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest\u0026apos;s APIC timer in periodic\nmode, set the expiration to \u0026quot;now\u0026quot; if the target expiration is in the past\n(similar to what is done in update_target_expiration()). Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over. In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active. As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past. As a result, the delta\nmay be calculated as a negative value. When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming. I.e. the large\nvalue will exceed the VMX Preemption Timer\u0026apos;s maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM\u0026apos;s request for an expiration in the past and\nimmediately re-invokes KVM\u0026apos;s callback after reprogramming. And because\nthe interrupt handler runs with IRQs disabled, restarting KVM\u0026apos;s hrtimer\nover and over until the target expiration is advanced to \u0026quot;now\u0026quot; can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n ...\n RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n ...\n RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n PKRU: 55555554\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n apic_timer_fn+0x31/0x50 [kvm]\n __hrtimer_run_queues+0x100/0x280\n hrtimer_interrupt+0x100/0x210\n ? ttwu_do_wakeup+0x19/0x160\n smp_apic_timer_interrupt+0x6a/0x130\n apic_timer_interrupt+0xf/0x20\n \u0026lt;/IRQ\u0026gt;\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\u0026quot;KVM: VMX: Move preemption timer \u0026lt;=\u0026gt; hrtimer dance to common x86\u0026quot;), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way. Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---(CVE-2025-71104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: make decode_pool() more resilient against corrupted osdmaps\n\nIf the osdmap is (maliciously) corrupted such that the encoded length\nof ceph_pg_pool envelope is less than what is expected for a particular\nencoding version, out-of-bounds reads may ensue because the only bounds\ncheck that is there is based on that length value.\n\nThis patch adds explicit bounds checks for each field that is decoded\nor skipped.(CVE-2025-71116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: seqiv - Do not use req-\u0026gt;iv after crypto_aead_encrypt\n\nAs soon as crypto_aead_encrypt is called, the underlying request\nmay be freed by an asynchronous completion. Thus dereferencing\nreq-\u0026gt;iv after it returns is invalid.\n\nInstead of checking req-\u0026gt;iv against info, create a new variable\nunaligned_info and use it for that purpose instead.(CVE-2025-71131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: change all pageblocks migrate type on coalescing\n\nWhen a page is freed it coalesces with a buddy into a higher order page\nwhile possible. When the buddy page migrate type differs, it is expected\nto be updated to match the one of the page being freed.\n\nHowever, only the first pageblock of the buddy page is updated, while the\nrest of the pageblocks are left unchanged.\n\nThat causes warnings in later expand() and other code paths (like below),\nsince an inconsistency between migration type of the list containing the\npage and the page-owned pageblocks migration types is introduced.\n\n[ 308.986589] ------------[ cut here ]------------\n[ 308.987227] page type is 0, passed migratetype is 1 (nr=256)\n[ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270\n[ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E)\n[ 308.987439] Unloaded tainted modules: hmac_s390(E):2\n[ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT\n[ 308.987657] Tainted: [E]=UNSIGNED_MODULE\n[ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0)\n[ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270)\n[ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3\n[ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88\n[ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300\n[ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008\n[ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0\n[ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4\n 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60\n #00000349976fa5fc: af000000\t\tmc\t0,0\n \u0026gt;00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498\n 00000349976fa604: b9040026\t\tlgr\t%r2,%r6\n 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906\n 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0\n 00000349976fa614: af000000\t\tmc\t0,0\n[ 308.987734] Call Trace:\n[ 308.987738] [\u0026lt;00000349976fa600\u0026gt;] expand+0x240/0x270\n[ 308.987744] ([\u0026lt;00000349976fa5fc\u0026gt;] expand+0x23c/0x270)\n[ 308.987749] [\u0026lt;00000349976ff95e\u0026gt;] rmqueue_bulk+0x71e/0x940\n[ 308.987754] [\u0026lt;00000349976ffd7e\u0026gt;] __rmqueue_pcplist+0x1fe/0x2a0\n[ 308.987759] [\u0026lt;0000034997700966\u0026gt;] rmqueue.isra.0+0xb46/0xf40\n[ 308.987763] [\u0026lt;0000034997703ec8\u0026gt;] get_page_from_freelist+0x198/0x8d0\n[ 308.987768] [\u0026lt;0000034997706fa8\u0026gt;] __alloc_frozen_pages_noprof+0x198/0x400\n[ 308.987774] [\u0026lt;00000349977536f8\u0026gt;] alloc_pages_mpol+0xb8/0x220\n[ 308.987781] [\u0026lt;0000034997753bf6\u0026gt;] folio_alloc_mpol_noprof+0x26/0xc0\n[ 308.987786] [\u0026lt;0000034997753e4c\u0026gt;] vma_alloc_folio_noprof+0x6c/0xa0\n[ 308.987791] [\u0026lt;0000034997775b22\u0026gt;] vma_alloc_anon_folio_pmd+0x42/0x240\n[ 308.987799] [\u0026lt;000003499777bfea\u0026gt;] __do_huge_pmd_anonymous_page+0x3a/0x210\n[ 308.987804] [\u0026lt;00000349976cb0\n---truncated---(CVE-2025-71134)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Fix a memory leak in tpm2_load_cmd\n\n\u0026apos;tpm2_load_cmd\u0026apos; allocates a tempoary blob indirectly via \u0026apos;tpm2_key_decode\u0026apos;\nbut it is not freed in the failure paths. Address this by wrapping the blob\ninto with a cleanup helper.(CVE-2025-71147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/poll: correctly handle io_poll_add() return value on update\n\nWhen the core of io_uring was updated to handle completions\nconsistently and with fixed return codes, the POLL_REMOVE opcode\nwith updates got slightly broken. If a POLL_ADD is pending and\nthen POLL_REMOVE is used to update the events of that request, if that\nupdate causes the POLL_ADD to now trigger, then that completion is lost\nand a CQE is never posted.\n\nAdditionally, ensure that if an update does cause an existing POLL_ADD\nto complete, that the completion value isn\u0026apos;t always overwritten with\n-ECANCELED. For that case, whatever io_poll_add() set the value to\nshould just be retained.(CVE-2025-71149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix refcount leak when invalid session is found on session lookup\n\nWhen a session is found but its state is not SMB2_SESSION_VALID, It\nindicates that no valid session was found, but it is missing to decrement\nthe reference count acquired by the session lookup, which results in\na reference count leak. This patch fixes the issue by explicitly calling\nksmbd_user_session_put to release the reference to the session.(CVE-2025-71150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn\u0026apos;t make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n the elevated refcount on the conduit\u0026apos;s kobject. Nominally, the OF and\n non-OF paths should result in objects having identical reference\n counts taken, and it is already suspicious that\n dsa_dev_to_net_device() has a put_device() call which is missing in\n dsa_port_parse_of(), but we can actually even verify that an issue\n exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n \u0026quot;before\u0026quot; and \u0026quot;after\u0026quot; applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 \u0026gt; /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: \u0026apos;eno2\u0026apos; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: \u0026apos;109\u0026apos; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n it can get unregistered at any time, and DSA remains with a long-lived,\n but in this case stale, cpu_dp-\u0026gt;conduit pointer. Holding the net\n device\u0026apos;s underlying kobject isn\u0026apos;t actually of much help, it just\n prevents it from being freed (but we never need that kobject\n directly). What helps us to prevent the net device from being\n unregistered is the parallel netdev reference mechanism (dev_hold()\n and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\u0026quot;net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\u0026quot;), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn\u0026apos;t know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n ports failed to probe, see commit 86f8b1c01a0a (\u0026quot;net: dsa: Do not\n make user port errors fatal\u0026quot;), and the cpu_dp-\u0026gt;conduit pointers\n remain valid. I haven\u0026apos;t audited all call paths to see whether they\n will actually use the conduit in lack of any user port, but if they\n do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n associated to, and we can get into a situation where we\u0026apos;ve moved all\n user ports away from a conduit, thus no longer hold any reference to\n it via the net device tracker. But we shouldn\u0026apos;t let it go nonetheless\n - see the next change in relation to dsa_tree_find_first_conduit()\n and LAG conduits which disappear.\n We have to be prepared to return to the physical conduit, so the CPU\n port must explicitly keep another reference to it. This is also to\n say: the user ports and their CPU ports may not always keep a\n reference to the same conduit net device, and both are needed.\n\nAs for the conduit\u0026apos;s kobject for the /sys/class/net/ entry, we don\u0026apos;t\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I\u0026apos;ll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---(CVE-2025-71152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: fix memory leak on usb_submit_urb() failure\n\nIn async_set_registers(), when usb_submit_urb() fails, the allocated\n async_req structure and URB are not freed, causing a memory leak.\n\n The completion callback async_set_reg_cb() is responsible for freeing\n these allocations, but it is only called after the URB is successfully\n submitted and completes (successfully or with error). If submission\n fails, the callback never runs and the memory is leaked.\n\n Fix this by freeing both the URB and the request structure in the error\n path when usb_submit_urb() fails.(CVE-2025-71154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix bsg_done() causing double free\n\nKernel panic observed on system,\n\n[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000\n[5353358.825194] #PF: supervisor write access in kernel mode\n[5353358.825195] #PF: error_code(0x0002) - not-present page\n[5353358.825196] PGD 100006067 P4D 0\n[5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1\n[5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025\n[5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10\n[5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246\n[5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000\n[5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000\n[5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000\n[5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090\n[5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000\n[5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000\n[5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0\n[5353358.825221] PKRU: 55555554\n[5353358.825222] Call Trace:\n[5353358.825223] \u0026lt;TASK\u0026gt;\n[5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df\n[5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df\n[5353358.825232] ? sg_copy_buffer+0xc8/0x110\n[5353358.825236] ? __die_body.cold+0x8/0xd\n[5353358.825238] ? page_fault_oops+0x134/0x170\n[5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110\n[5353358.825244] ? exc_page_fault+0xa8/0x150\n[5353358.825247] ? asm_exc_page_fault+0x22/0x30\n[5353358.825252] ? memcpy_erms+0x6/0x10\n[5353358.825253] sg_copy_buffer+0xc8/0x110\n[5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx]\n[5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx]\n\nMost routines in qla_bsg.c call bsg_done() only for success cases.\nHowever a few invoke it for failure case as well leading to a double\nfree. Validate before calling bsg_done().(CVE-2025-71238)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: avoid kernel-infoleak from struct iw_point\n\nstruct iw_point has a 32bit hole on 64bit arches.\n\nstruct iw_point {\n void __user *pointer; /* Pointer to the data (in user space) */\n __u16 length; /* number of fields or size in bytes */\n __u16 flags; /* Optional params */\n};\n\nMake sure to zero the structure to avoid disclosing 32bits of kernel data\nto user space.(CVE-2026-22978)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: provide locking for v4_end_grace\n\nWriting to v4_end_grace can race with server shutdown and result in\nmemory being accessed after it was freed - reclaim_str_hashtbl in\nparticularly.\n\nWe cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is\nheld while client_tracking_op-\u0026gt;init() is called and that can wait for\nan upcall to nfsdcltrack which can write to v4_end_grace, resulting in a\ndeadlock.\n\nnfsd4_end_grace() is also called by the landromat work queue and this\ndoesn\u0026apos;t require locking as server shutdown will stop the work and wait\nfor it before freeing anything that nfsd4_end_grace() might access.\n\nHowever, we must be sure that writing to v4_end_grace doesn\u0026apos;t restart\nthe work item after shutdown has already waited for it. For this we\nadd a new flag protected with nn-\u0026gt;client_lock. It is set only while it\nis safe to make client tracking calls, and v4_end_grace only schedules\nwork while the flag is set with the spinlock held.\n\nSo this patch adds a nfsd_net field \u0026quot;client_tracking_active\u0026quot; which is\nset as described. Another field \u0026quot;grace_end_forced\u0026quot;, is set when\nv4_end_grace is written. After this is set, and providing\nclient_tracking_active is set, the laundromat is scheduled.\nThis \u0026quot;grace_end_forced\u0026quot; field bypasses other checks for whether the\ngrace period has finished.\n\nThis resolves a race which can result in use-after-free.(CVE-2026-22980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: replace overzealous BUG_ON in osdmap_apply_incremental()\n\nIf the osdmap is (maliciously) corrupted such that the incremental\nosdmap epoch is different from what is expected, there is no need to\nBUG. Instead, just declare the incremental osdmap to be invalid.(CVE-2026-22990)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: return the handler error from mon_handle_auth_done()\n\nCurrently any error from ceph_auth_handle_reply_done() is propagated\nvia finish_auth() but isn\u0026apos;t returned from mon_handle_auth_done(). This\nresults in higher layers learning that (despite the monitor considering\nus to be successfully authenticated) something went wrong in the\nauthentication phase and reacting accordingly, but msgr2 still trying\nto proceed with establishing the session in the background. In the\ncase of secure mode this can trigger a WARN in setup_crypto() and later\nlead to a NULL pointer dereference inside of prepare_auth_signature().(CVE-2026-22992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Don\u0026apos;t store mlx5e_priv in mlx5e_dev devlink priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails, mlx5e_priv in mlx5e_dev devlink private is used to\nreference the netdev and mdev associated with that struct. Instead,\nstore netdev directly into mlx5e_dev and get mdev from the containing\nmlx5_adev aux device structure.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==\u0026gt; oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000520\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_remove+0x68/0x130\nRSP: 0018:ffffc900034838f0 EFLAGS: 00010246\nRAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\nRBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10\nR10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0\nR13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400\nFS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-22996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\u0026quot;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\u0026quot;)\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command\u0026apos;s data structures (cmd-\u0026gt;req.sg and cmd-\u0026gt;iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT \u2192 both pointers NULL\n2. H2C_DATA PDU for READ command \u2192 cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n3. H2C_DATA PDU for uninitialized command slot \u2192 both pointers NULL\n\nThe fix validates both cmd-\u0026gt;req.sg and cmd-\u0026gt;iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n- WRITE commands: both allocated(CVE-2026-22998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash on profile change rollback failure\n\nmlx5e_netdev_change_profile can fail to attach a new profile and can\nfail to rollback to old profile, in such case, we could end up with a\ndangling netdev with a fully reset netdev_priv. A retry to change\nprofile, e.g. another attempt to call mlx5e_netdev_change_profile via\nswitchdev mode change, will crash trying to access the now NULL\npriv-\u0026gt;mdev.\n\nThis fix allows mlx5e_netdev_change_profile() to handle previous\nfailures and an empty priv, by not assuming priv is valid.\n\nPass netdev and mdev to all flows requiring\nmlx5e_netdev_change_profile() and avoid passing priv.\nIn mlx5e_netdev_change_profile() check if current priv is valid, and if\nnot, just attach the new profile without trying to access the old one.\n\nThis fixes the following oops, when enabling switchdev mode for the 2nd\ntime after first time failure:\n\n ## Enabling switchdev mode first time:\n\nmlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n ^^^^^^^^\nmlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\n\n ## retry: Enabling switchdev mode 2nd time:\n\nmlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload\nBUG: kernel NULL pointer dereference, address: 0000000000000038\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_detach_netdev+0x3c/0x90\nCode: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 \u0026lt;48\u0026gt; 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07\nRSP: 0018:ffffc90000673890 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000\nRDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000\nR10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000\nR13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000\nFS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_netdev_change_profile+0x45/0xb0\n mlx5e_vport_rep_load+0x27b/0x2d0\n mlx5_esw_offloads_rep_load+0x72/0xf0\n esw_offloads_enable+0x5d0/0x970\n mlx5_eswitch_enable_locked+0x349/0x430\n ? is_mp_supported+0x57/0xb0\n mlx5_devlink_eswitch_mode_set+0x26b/0x430\n devlink_nl_eswitch_set_doit+0x6f/0xf0\n genl_family_rcv_msg_doit+0xe8/0x140\n genl_rcv_msg+0x18b/0x290\n ? __pfx_devlink_nl_pre_doit+0x10/0x10\n ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10\n ? __pfx_devlink_nl_post_doit+0x10/0x10\n ? __pfx_genl_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x52/0x100\n genl_rcv+0x28/0x40\n netlink_unicast+0x282/0x3e0\n ? __alloc_skb+0xd6/0x190\n netlink_sendmsg+0x1f7/0x430\n __sys_sendto+0x213/0x220\n ? __sys_recvmsg+0x6a/0xd0\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fdfb8495047(CVE-2026-23000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1\n\nWhen loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in\nresponse to a guest WRMSR, clear XFD-disabled features in the saved (or to\nbe restored) XSTATE_BV to ensure KVM doesn\u0026apos;t attempt to load state for\nfeatures that are disabled via the guest\u0026apos;s XFD. Because the kernel\nexecutes XRSTOR with the guest\u0026apos;s XFD, saving XSTATE_BV[i]=1 with XFD[i]=1\nwill cause XRSTOR to #NM and panic the kernel.\n\nE.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:\n\n ------------[ cut here ]------------\n WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:exc_device_not_available+0x101/0x110\n Call Trace:\n \u0026lt;TASK\u0026gt;\n asm_exc_device_not_available+0x1a/0x20\n RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n switch_fpu_return+0x4a/0xb0\n kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]\n kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n __x64_sys_ioctl+0x8f/0xd0\n do_syscall_64+0x62/0x940\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nThis can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,\nand a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler\u0026apos;s\ncall to fpu_update_guest_xfd().\n\nand if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:\n\n ------------[ cut here ]------------\n WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:exc_device_not_available+0x101/0x110\n Call Trace:\n \u0026lt;TASK\u0026gt;\n asm_exc_device_not_available+0x1a/0x20\n RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n fpu_swap_kvm_fpstate+0x6b/0x120\n kvm_load_guest_fpu+0x30/0x80 [kvm]\n kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]\n kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n __x64_sys_ioctl+0x8f/0xd0\n do_syscall_64+0x62/0x940\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nThe new behavior is consistent with the AMX architecture. Per Intel\u0026apos;s SDM,\nXSAVE saves XSTATE_BV as \u0026apos;0\u0026apos; for components that are disabled via XFD\n(and non-compacted XSAVE saves the initial configuration of the state\ncomponent):\n\n If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,\n the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;\n instead, it operates as if XINUSE[i] = 0 (and the state component was\n in its initial state): it saves bit i of XSTATE_BV field of the XSAVE\n header as 0; in addition, XSAVE saves the initial configuration of the\n state component (the other instructions do not save state component i).\n\nAlternatively, KVM could always do XRSTOR with XFD=0, e.g. by using\na constant XFD based on the set of enabled features when XSAVEing for\na struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled\nfeatures can only happen in the above interrupt case, or in similar\nscenarios involving preemption on preemptible kernels, because\nfpu_swap_kvm_fpstate()\u0026apos;s call to save_fpregs_to_fpstate() saves the\noutgoing FPU state with the current XFD; and that is (on all but the\nfirst WRMSR to XFD) the guest XFD.\n\nTherefore, XFD can only go out of sync with XSTATE_BV in the above\ninterrupt case, or in similar scenarios involving preemption on\npreemptible kernels, and it we can consider it (de facto) part of KVM\nABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.\n\n[Move clea\n---truncated---(CVE-2026-23005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails.\n\nPass netdev to mlx5e_destroy_netdev() to guarantee it will work on a\nvalid netdev.\n\nOn mlx5e_remove: Check validity of priv-\u0026gt;profile, before attempting\nto cleanup any resources that might be not there.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==\u0026gt; oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000370\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100\nRSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286\nRAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0\nRBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10\nR10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0\nR13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400\nFS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_remove+0x57/0x110\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-23035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: authencesn - reject too-short AAD (assoclen\u0026lt;8) to match ESP/ESN spec\n\nauthencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than\nthe minimum expected length, crypto_authenc_esn_decrypt() can advance past\nthe end of the destination scatterlist and trigger a NULL pointer dereference\nin scatterwalk_map_and_copy(), leading to a kernel panic (DoS).\n\nAdd a minimum AAD length check to fail fast on invalid inputs.(CVE-2026-23060)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: fix potential underflow in virtio_transport_get_credit()\n\nThe credit calculation in virtio_transport_get_credit() uses unsigned\narithmetic:\n\n ret = vvs-\u0026gt;peer_buf_alloc - (vvs-\u0026gt;tx_cnt - vvs-\u0026gt;peer_fwd_cnt);\n\nIf the peer shrinks its advertised buffer (peer_buf_alloc) while bytes\nare in flight, the subtraction can underflow and produce a large\npositive value, potentially allowing more data to be queued than the\npeer can handle.\n\nReuse virtio_transport_has_space() which already handles this case and\nadd a comment to make it clear why we are doing that.\n\n[Stefano: use virtio_transport_has_space() instead of duplicating the code]\n[Stefano: tweak the commit message](CVE-2026-23069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregmap: Fix race condition in hwspinlock irqsave routine\n\nPreviously, the address of the shared member \u0026apos;\u0026amp;map-\u0026gt;spinlock_flags\u0026apos; was\npassed directly to \u0026apos;hwspin_lock_timeout_irqsave\u0026apos;. This creates a race\ncondition where multiple contexts contending for the lock could overwrite\nthe shared flags variable, potentially corrupting the state for the\ncurrent lock owner.\n\nFix this by using a local stack variable \u0026apos;flags\u0026apos; to store the IRQ state\ntemporarily.(CVE-2026-23071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: cap TX credit to local buffer size\n\nThe virtio transports derives its TX credit directly from peer_buf_alloc,\nwhich is set from the remote endpoint\u0026apos;s SO_VM_SOCKETS_BUFFER_SIZE value.\n\nOn the host side this means that the amount of data we are willing to\nqueue for a connection is scaled by a guest-chosen buffer size, rather\nthan the host\u0026apos;s own vsock configuration. A malicious guest can advertise\na large buffer and read slowly, causing the host to allocate a\ncorrespondingly large amount of sk_buff memory.\nThe same thing would happen in the guest with a malicious host, since\nvirtio transports share the same code base.\n\nIntroduce a small helper, virtio_transport_tx_buf_size(), that\nreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consume\npeer_buf_alloc.\n\nThis ensures the effective TX window is bounded by both the peer\u0026apos;s\nadvertised buffer and our own buf_alloc (already clamped to\nbuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer\ncannot force the other to queue more data than allowed by its own\nvsock settings.\n\nOn an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with\n32 guest vsock connections advertising 2 GiB each and reading slowly\ndrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only\nrecovered after killing the QEMU process. That said, if QEMU memory is\nlimited with cgroups, the maximum memory used will be limited.\n\nWith this patch applied:\n\n Before:\n MemFree: ~61.6 GiB\n Slab: ~142 MiB\n SUnreclaim: ~117 MiB\n\n After 32 high-credit connections:\n MemFree: ~61.5 GiB\n Slab: ~178 MiB\n SUnreclaim: ~152 MiB\n\nOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest\nremains responsive.\n\nCompatibility with non-virtio transports:\n\n - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per\n socket based on the local vsk-\u0026gt;buffer_* values; the remote side\n cannot enlarge those queues beyond what the local endpoint\n configured.\n\n - Hyper-V\u0026apos;s vsock transport uses fixed-size VMBus ring buffers and\n an MTU bound; there is no peer-controlled credit field comparable\n to peer_buf_alloc, and the remote endpoint cannot drive in-flight\n kernel memory above those ring sizes.\n\n - The loopback path reuses virtio_transport_common.c, so it\n naturally follows the same semantics as the virtio transport.\n\nThis change is limited to virtio_transport_common.c and thus affects\nvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the\n\u0026quot;remote window intersected with local policy\u0026quot; behaviour that VMCI and\nHyper-V already effectively have.\n\n[Stefano: small adjustments after changing the previous patch]\n[Stefano: tweak the commit message](CVE-2026-23086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: limit BOND_MODE_8023AD to Ethernet devices\n\nBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.\n\nsyzbot reported:\n\n BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\nRead of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497\n\nCPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)\nTainted: [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n check_region_inline mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200\n __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\n __dev_mc_add net/core/dev_addr_lists.c:868 [inline]\n dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886\n bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180\n do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963\n do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165\n rtnl_changelink net/core/rtnetlink.c:3776 [inline]\n __rtnl_newlink net/core/rtnetlink.c:3935 [inline]\n rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072\n rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958\n netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550\n netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]\n netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344\n netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n ____sys_sendmsg+0x505/0x820 net/socket.c:2592\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646\n __sys_sendmsg+0x164/0x220 net/socket.c:2678\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307\n do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n \u0026lt;/TASK\u0026gt;\n\nThe buggy address belongs to the variable:\n lacpdu_mcast_addr+0x0/0x40(CVE-2026-23099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: Make the addrs_lock be per port\n\nMake the addrs_lock be per port, not per ipvlan dev.\n\nInitial code seems to be written in the assumption,\nthat any address change must occur under RTNL.\nBut it is not so for the case of IPv6. So\n\n1) Introduce per-port addrs_lock.\n\n2) It was needed to fix places where it was forgotten\nto take lock (ipvlan_open/ipvlan_close)\n\nThis appears to be a very minor problem though.\nSince it\u0026apos;s highly unlikely that ipvlan_add_addr() will\nbe called on 2 CPU simultaneously. But nevertheless,\nthis could cause:\n\n1) False-negative of ipvlan_addr_busy(): one interface\niterated through all port-\u0026gt;ipvlans + ipvlan-\u0026gt;addrs\nunder some ipvlan spinlock, and another added IP\nunder its own lock. Though this is only possible\nfor IPv6, since looks like only ipvlan_addr6_event() can be\ncalled without rtnl_lock.\n\n2) Race since ipvlan_ht_addr_add(port) is called under\ndifferent ipvlan-\u0026gt;addrs_lock locks\n\nThis should not affect performance, since add/remove IP\nis a rare situation and spinlock is not taken on fast\npaths.(CVE-2026-23103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag\n\nThis is more of a preventive patch to make the code more consistent and\nto prevent possible exploits that employ child qlen manipulations on qfq.\nuse cl_is_active instead of relying on the child qdisc\u0026apos;s qlen to determine\nclass activation.(CVE-2026-23105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()\n\nnft_map_catchall_activate() has an inverted element activity check\ncompared to its non-catchall counterpart nft_mapelem_activate() and\ncompared to what is logically required.\n\nnft_map_catchall_activate() is called from the abort path to re-activate\ncatchall map elements that were deactivated during a failed transaction.\nIt should skip elements that are already active (they don\u0026apos;t need\nre-activation) and process elements that are inactive (they need to be\nrestored). Instead, the current code does the opposite: it skips inactive\nelements and processes active ones.\n\nCompare the non-catchall activate callback, which is correct:\n\n nft_mapelem_activate():\n if (nft_set_elem_active(ext, iter-\u0026gt;genmask))\n return 0; /* skip active, process inactive */\n\nWith the buggy catchall version:\n\n nft_map_catchall_activate():\n if (!nft_set_elem_active(ext, genmask))\n continue; /* skip inactive, process active */\n\nThe consequence is that when a DELSET operation is aborted,\nnft_setelem_data_activate() is never called for the catchall element.\nFor NFT_GOTO verdict elements, this means nft_data_hold() is never\ncalled to restore the chain-\u0026gt;use reference count. Each abort cycle\npermanently decrements chain-\u0026gt;use. Once chain-\u0026gt;use reaches zero,\nDELCHAIN succeeds and frees the chain while catchall verdict elements\nstill reference it, resulting in a use-after-free.\n\nThis is exploitable for local privilege escalation from an unprivileged\nuser via user namespaces + nftables on distributions that enable\nCONFIG_USER_NS and CONFIG_NF_TABLES.\n\nFix by removing the negation so the check matches nft_mapelem_activate():\nskip active elements, process inactive ones.(CVE-2026-23111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: avoid one data-race in l2tp_tunnel_del_work()\n\nWe should read sk-\u0026gt;sk_socket only when dealing with kernel sockets.\n\nsyzbot reported the following data-race:\n\nBUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release\n\nwrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:\n sk_set_socket include/net/sock.h:2092 [inline]\n sock_orphan include/net/sock.h:2118 [inline]\n sk_common_release+0xae/0x230 net/core/sock.c:4003\n udp_lib_close+0x15/0x20 include/net/udp.h:325\n inet_release+0xce/0xf0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:662 [inline]\n sock_close+0x6b/0x150 net/socket.c:1455\n __fput+0x29b/0x650 fs/file_table.c:468\n ____fput+0x1c/0x30 fs/file_table.c:496\n task_work_run+0x131/0x1a0 kernel/task_work.c:233\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]\n exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75\n __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]\n syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]\n do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:\n l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418\n process_one_work kernel/workqueue.c:3257 [inline]\n process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340\n worker_thread+0x582/0x770 kernel/workqueue.c:3421\n kthread+0x489/0x510 kernel/kthread.c:463\n ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n\nvalue changed: 0xffff88811b818000 -\u0026gt; 0x0000000000000000(CVE-2026-23120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: annotate data-race in ndisc_router_discovery()\n\nsyzbot found that ndisc_router_discovery() could read and write\nin6_dev-\u0026gt;ra_mtu without holding a lock [1]\n\nThis looks fine, IFLA_INET6_RA_MTU is best effort.\n\nAdd READ_ONCE()/WRITE_ONCE() to document the race.\n\nNote that we might also reject illegal MTU values\n(mtu \u0026lt; IPV6_MIN_MTU || mtu \u0026gt; skb-\u0026gt;dev-\u0026gt;mtu) in a future patch.\n\n[1]\nBUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery\n\nread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1:\n ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558\n ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841\n icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989\n ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438\n ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489\n NF_HOOK include/linux/netfilter.h:318 [inline]\n ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500\n ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590\n dst_input include/net/dst.h:474 [inline]\n ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79\n...\n\nwrite to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0:\n ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559\n ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841\n icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989\n ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438\n ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489\n NF_HOOK include/linux/netfilter.h:318 [inline]\n ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500\n ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590\n dst_input include/net/dst.h:474 [inline]\n ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79\n...\n\nvalue changed: 0x00000000 -\u0026gt; 0xe5400659(CVE-2026-23124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: fix a race issue related to the operation on bpf_bound_progs list\n\nThe netdevsim driver lacks a protection mechanism for operations on the\nbpf_bound_progs list. When the nsim_bpf_create_prog() performs\nlist_add_tail, it is possible that nsim_bpf_destroy_prog() is\nsimultaneously performs list_del. Concurrent operations on the list may\nlead to list corruption and trigger a kernel crash as follows:\n\n[ 417.290971] kernel BUG at lib/list_debug.c:62!\n[ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1\n[ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 417.291007] Workqueue: events bpf_prog_free_deferred\n[ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0\n[ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff \u0026lt;0f\u0026gt; 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8\n[ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246\n[ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000\n[ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180\n[ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003\n[ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20\n[ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000\n[ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000\n[ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0\n[ 417.291088] PKRU: 55555554\n[ 417.291091] Call Trace:\n[ 417.291096] \u0026lt;TASK\u0026gt;\n[ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim]\n[ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80\n[ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0\n[ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0\n[ 417.291178] process_one_work+0x18a/0x3a0\n[ 417.291188] worker_thread+0x27b/0x3a0\n[ 417.291197] ? __pfx_worker_thread+0x10/0x10\n[ 417.291207] kthread+0xe5/0x120\n[ 417.291214] ? __pfx_kthread+0x10/0x10\n[ 417.291221] ret_from_fork+0x31/0x50\n[ 417.291230] ? __pfx_kthread+0x10/0x10\n[ 417.291236] ret_from_fork_asm+0x1a/0x30\n[ 417.291246] \u0026lt;/TASK\u0026gt;\n\nAdd a mutex lock, to prevent simultaneous addition and deletion operations\non the list.(CVE-2026-23126)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: fix dma_free_coherent() pointer\n\ndma_alloc_coherent() allocates a DMA mapped buffer and stores the\naddresses in XXX_unaligned fields. Those should be reused when freeing\nthe buffer rather than the aligned addresses.(CVE-2026-23133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: reset sparse-read state in osd_fault()\n\nWhen a fault occurs, the connection is abandoned, reestablished, and any\npending operations are retried. The OSD client tracks the progress of a\nsparse-read reply using a separate state machine, largely independent of\nthe messenger\u0026apos;s state.\n\nIf a connection is lost mid-payload or the sparse-read state machine\nreturns an error, the sparse-read state is not reset. The OSD client\nwill then interpret the beginning of a new reply as the continuation of\nthe old one. If this makes the sparse-read machinery enter a failure\nstate, it may never recover, producing loops like:\n\n libceph: [0] got 0 extents\n libceph: data len 142248331 != extent len 0\n libceph: osd0 (1)...:6801 socket error on read\n libceph: data len 142248331 != extent len 0\n libceph: osd0 (1)...:6801 socket error on read\n\nTherefore, reset the sparse-read state in osd_fault(), ensuring retries\nstart from a clean state.(CVE-2026-23136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nof: unittest: Fix memory leak in unittest_data_add()\n\nIn unittest_data_add(), if of_resolve_phandles() fails, the allocated\nunittest_data is not freed, leading to a memory leak.\n\nFix this by using scope-based cleanup helper __free(kfree) for automatic\nresource cleanup. This ensures unittest_data is automatically freed when\nit goes out of scope in error paths.\n\nFor the success path, use retain_and_null_ptr() to transfer ownership\nof the memory to the device tree and prevent double freeing.(CVE-2026-23137)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add recursion protection in kernel stack trace recording\n\nA bug was reported about an infinite recursion caused by tracing the rcu\nevents with the kernel stack trace trigger enabled. The stack trace code\ncalled back into RCU which then called the stack trace again.\n\nExpand the ftrace recursion protection to add a set of bits to protect\nevents from recursion. Each bit represents the context that the event is\nin (normal, softirq, interrupt and NMI).\n\nHave the stack trace code use the interrupt context to protect against\nrecursion.\n\nNote, the bug showed an issue in both the RCU code as well as the tracing\nstacktrace code. This only handles the tracing stack trace side of the\nbug. The RCU fix will be handled separately.(CVE-2026-23138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conncount: update last_gc only when GC has been performed\n\nCurrently last_gc is being updated everytime a new connection is\ntracked, that means that it is updated even if a GC wasn\u0026apos;t performed.\nWith a sufficiently high packet rate, it is possible to always bypass\nthe GC, causing the list to grow infinitely.\n\nUpdate the last_gc value only when a GC has been actually performed.(CVE-2026-23139)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix iloc.bh leak in ext4_xattr_inode_update_ref\n\nThe error branch for ext4_xattr_inode_update_ref forget to release the\nrefcount for iloc.bh. Find this when review code.(CVE-2026-23145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix segmentation of forwarding fraglist GRO\n\nThis patch enhances GSO segment handling by properly checking\nthe SKB_GSO_DODGY flag for frag_list GSO packets, addressing\nlow throughput issues observed when a station accesses IPv4\nservers via hotspots with an IPv6-only upstream interface.\n\nSpecifically, it fixes a bug in GSO segmentation when forwarding\nGRO packets containing a frag_list. The function skb_segment_list\ncannot correctly process GRO skbs that have been converted by XLAT,\nsince XLAT only translates the header of the head skb. Consequently,\nskbs in the frag_list may remain untranslated, resulting in protocol\ninconsistencies and reduced throughput.\n\nTo address this, the patch explicitly sets the SKB_GSO_DODGY flag\nfor GSO packets in XLAT\u0026apos;s IPv4/IPv6 protocol translation helpers\n(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSO\npackets as potentially modified after protocol translation. As a\nresult, GSO segmentation will avoid using skb_segment_list and\ninstead falls back to skb_segment for packets with the SKB_GSO_DODGY\nflag. This ensures that only safe and fully translated frag_list\npackets are processed by skb_segment_list, resolving protocol\ninconsistencies and improving throughput when forwarding GRO packets\nconverted by XLAT.(CVE-2026-23154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: fix error propagation in efivar_entry_get()\n\nefivar_entry_get() always returns success even if the underlying\n__efivar_entry_get() fails, masking errors.\n\nThis may result in uninitialized heap memory being copied to userspace\nin the efivarfs_file_read() path.\n\nFix it by returning the error from __efivar_entry_get().(CVE-2026-23156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix race in mptcp_pm_nl_flush_addrs_doit()\n\nsyzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()\nand/or mptcp_pm_nl_is_backup()\n\nRoot cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()\nwhich is not RCU ready.\n\nlist_splice_init_rcu() can not be called here while holding pernet-\u0026gt;lock\nspinlock.\n\nMany thanks to Eulgyu Kim for providing a repro and testing our patches.(CVE-2026-23169)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: TC, delete flows only for existing peers\n\nWhen deleting TC steering flows, iterate only over actual devcom\npeers instead of assuming all possible ports exist. This avoids\ntouching non-existent peers and ensures cleanup is limited to\ndevices the driver is currently connected to.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 133c8a067 P4D 0\n Oops: Oops: 0002 [#1] SMP\n CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core]\n Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff \u0026lt;48\u0026gt; 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49\n RSP: 0018:ff11000143867528 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000\n RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0\n RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002\n R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78\n R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0\n FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]\n mlx5e_flow_put+0x25/0x50 [mlx5_core]\n mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]\n tc_setup_cb_reoffload+0x20/0x80\n fl_reoffload+0x26f/0x2f0 [cls_flower]\n ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]\n ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]\n tcf_block_playback_offloads+0x9e/0x1c0\n tcf_block_unbind+0x7b/0xd0\n tcf_block_setup+0x186/0x1d0\n tcf_block_offload_cmd.isra.0+0xef/0x130\n tcf_block_offload_unbind+0x43/0x70\n __tcf_block_put+0x85/0x160\n ingress_destroy+0x32/0x110 [sch_ingress]\n __qdisc_destroy+0x44/0x100\n qdisc_graft+0x22b/0x610\n tc_get_qdisc+0x183/0x4d0\n rtnetlink_rcv_msg+0x2d7/0x3d0\n ? rtnl_calcit.isra.0+0x100/0x100\n netlink_rcv_skb+0x53/0x100\n netlink_unicast+0x249/0x320\n ? __alloc_skb+0x102/0x1f0\n netlink_sendmsg+0x1e3/0x420\n __sock_sendmsg+0x38/0x60\n ____sys_sendmsg+0x1ef/0x230\n ? copy_msghdr_from_user+0x6c/0xa0\n ___sys_sendmsg+0x7f/0xc0\n ? ___sys_recvmsg+0x8a/0xc0\n ? __sys_sendto+0x119/0x180\n __sys_sendmsg+0x61/0xb0\n do_syscall_64+0x55/0x640\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f35238bb764\n Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55\n RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764\n RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003\n RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20\n R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790\n R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780(CVE-2026-23173)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: aloop: Fix racy access at PCM trigger\n\nThe PCM trigger callback of aloop driver tries to check the PCM state\nand stop the stream of the tied substream in the corresponding cable.\nSince both check and stop operations are performed outside the cable\nlock, this may result in UAF when a program attempts to trigger\nfrequently while opening/closing the tied stream, as spotted by\nfuzzers.\n\nFor addressing the UAF, this patch changes two things:\n- It covers the most of code in loopback_check_format() with\n cable-\u0026gt;lock spinlock, and add the proper NULL checks. This avoids\n already some racy accesses.\n- In addition, now we try to check the state of the capture PCM stream\n that may be stopped in this function, which was the major pain point\n leading to UAF.(CVE-2026-23191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Don\u0026apos;t clobber irqfd routing type when deassigning irqfd\n\nWhen deassigning a KVM_IRQFD, don\u0026apos;t clobber the irqfd\u0026apos;s copy of the IRQ\u0026apos;s\nrouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86\nand arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to\nhandle a concurrent routing update, verify that the irqfd is still active\nbefore consuming the routing information. As evidenced by the x86 and\narm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),\nclobbering the entry type without notifying arch code is surprising and\nerror prone.\n\nAs a bonus, checking that the irqfd is active provides a convenient\nlocation for documenting _why_ KVM must not consume the routing entry for\nan irqfd that is in the process of being deassigned: once the irqfd is\ndeleted from the list (which happens *before* the eventfd is detached), it\nwill no longer receive updates via kvm_irq_routing_update(), and so KVM\ncould deliver an event using stale routing information (relative to\nKVM_SET_GSI_ROUTING returning to userspace).\n\nAs an even better bonus, explicitly checking for the irqfd being active\nfixes a similar bug to the one the clobbering is trying to prevent: if an\nirqfd is deactivated, and then its routing is changed,\nkvm_irq_routing_update() won\u0026apos;t invoke kvm_arch_update_irqfd_routing()\n(because the irqfd isn\u0026apos;t in the list). And so if the irqfd is in bypass\nmode, IRQs will continue to be posted using the old routing information.\n\nAs for kvm_arch_irq_bypass_del_producer(), clobbering the routing type\nresults in KVM incorrectly keeping the IRQ in bypass mode, which is\nespecially problematic on AMD as KVM tracks IRQs that are being posted to\na vCPU in a list whose lifetime is tied to the irqfd.\n\nWithout the help of KASAN to detect use-after-free, the most common\nsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to\nthe memory for irqfd structure being re-allocated and zeroed, resulting\nin irqfd-\u0026gt;irq_bypass_data being NULL when read by\navic_update_iommu_vcpu_affinity():\n\n BUG: kernel NULL pointer dereference, address: 0000000000000018\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test\n Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n RIP: 0010:amd_iommu_update_ga+0x19/0xe0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]\n __avic_vcpu_load+0xf4/0x130 [kvm_amd]\n kvm_arch_vcpu_load+0x89/0x210 [kvm]\n vcpu_load+0x30/0x40 [kvm]\n kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]\n kvm_vcpu_ioctl+0x571/0x6a0 [kvm]\n __se_sys_ioctl+0x6d/0xb0\n do_syscall_64+0x6f/0x9d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x46893b\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nIf AVIC is inhibited when the irfd is deassigned, the bug will manifest as\nlist corruption, e.g. on the next irqfd assignment.\n\n list_add corruption. next-\u0026gt;prev should be prev (ffff8d474d5cd588),\n but was 0000000000000000. (next=ffff8d8658f86530).\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:31!\n Oops: invalid opcode: 0000 [#1] SMP\n CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test\n Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n RIP: 0010:__list_add_valid_or_report+0x97/0xc0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]\n kvm_pi_update_irte+0xbf/0x190 [kvm]\n kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]\n irq_bypass_register_consumer+0xcd/0x170 [irqbypa\n---truncated---(CVE-2026-23198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_u32: use skb_header_pointer_careful()\n\nskb_header_pointer() does not fully validate negative @offset values.\n\nUse skb_header_pointer_careful() instead.\n\nGangMin Kim provided a report and a repro fooling u32_classify():\n\nBUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0\nnet/sched/cls_u32.c:221(CVE-2026-23204)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Prevent excessive number of frames\n\nIn this case, the user constructed the parameters with maxpacksize 40\nfor rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer\nsize for each data URB is maxpacksize * packets, which in this example\nis 40 * 6 = 240; When the user performs a write operation to send audio\ndata into the ALSA PCM playback stream, the calculated number of frames\nis packsize[0] * packets = 264, which exceeds the allocated URB buffer\nsize, triggering the out-of-bounds (OOB) issue reported by syzbot [1].\n\nAdded a check for the number of single data URB frames when calculating\nthe number of frames to prevent [1].\n\n[1]\nBUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\nWrite of size 264 at addr ffff88804337e800 by task syz.0.17/5506\nCall Trace:\n copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\n prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611\n prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333(CVE-2026-23208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: annotate data-races around slave-\u0026gt;last_rx\n\nslave-\u0026gt;last_rx and slave-\u0026gt;target_last_arp_rx[...] can be read and written\nlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.\n\nsyzbot reported:\n\nBUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1:\n bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n netif_receive_skb_internal net/core/dev.c:6351 [inline]\n netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n...\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0:\n bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n netif_receive_skb_internal net/core/dev.c:6351 [inline]\n netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n br_netif_receive_skb net/bridge/br_input.c:30 [inline]\n NF_HOOK include/linux/netfilter.h:318 [inline]\n...\n\nvalue changed: 0x0000000100005365 -\u0026gt; 0x0000000100005366(CVE-2026-23212)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix use-after-free in driver_override_show()\n\nThe driver_override_show() function reads the driver_override string\nwithout holding the device_lock. However, driver_override_store() uses\ndriver_set_override(), which modifies and frees the string while holding\nthe device_lock.\n\nThis can result in a concurrent use-after-free if the string is freed\nby the store function while being read by the show function.\n\nFix this by holding the device_lock around the read operation.(CVE-2026-23221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: split cached_fid bitfields to avoid shared-byte RMW races\n\nis_open, has_lease and on_list are stored in the same bitfield byte in\nstruct cached_fid but are updated in different code paths that may run\nconcurrently. Bitfield assignments generate byte read\u2013modify\u2013write\noperations (e.g. `orb $mask, addr` on x86_64), so updating one flag can\nrestore stale values of the others.\n\nA possible interleaving is:\n CPU1: load old byte (has_lease=1, on_list=1)\n CPU2: clear both flags (store 0)\n CPU1: RMW store (old | IS_OPEN) -\u0026gt; reintroduces cleared bits\n\nTo avoid this class of races, convert these flags to separate bool\nfields.(CVE-2026-23230)",
"id": "OESA-2026-1760",
"modified": "2026-08-06T11:10:47Z",
"published": "2026-03-27T11:10:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38373"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38659"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40030"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40215"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40220"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40242"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40251"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40272"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40277"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40294"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40308"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40318"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40341"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40343"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40346"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40351"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40358"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40359"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40361"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68173"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68174"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68188"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68200"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68206"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68208"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68235"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68264"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68297"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68331"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68337"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68349"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68354"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68362"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68363"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68376"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71116"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71134"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71147"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71238"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22980"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23060"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23069"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23120"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23124"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23126"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23133"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23136"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23137"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23139"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23169"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23173"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23191"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23204"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23208"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23212"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23221"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23230"
}
],
"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-2024-53232",
"CVE-2025-37900",
"CVE-2025-37954",
"CVE-2025-38083",
"CVE-2025-38373",
"CVE-2025-38556",
"CVE-2025-38591",
"CVE-2025-38659",
"CVE-2025-38730",
"CVE-2025-39713",
"CVE-2025-39961",
"CVE-2025-40030",
"CVE-2025-40096",
"CVE-2025-40215",
"CVE-2025-40220",
"CVE-2025-40237",
"CVE-2025-40242",
"CVE-2025-40251",
"CVE-2025-40271",
"CVE-2025-40272",
"CVE-2025-40277",
"CVE-2025-40294",
"CVE-2025-40301",
"CVE-2025-40308",
"CVE-2025-40318",
"CVE-2025-40341",
"CVE-2025-40342",
"CVE-2025-40343",
"CVE-2025-40346",
"CVE-2025-40351",
"CVE-2025-40358",
"CVE-2025-40359",
"CVE-2025-40361",
"CVE-2025-68171",
"CVE-2025-68173",
"CVE-2025-68174",
"CVE-2025-68176",
"CVE-2025-68188",
"CVE-2025-68200",
"CVE-2025-68206",
"CVE-2025-68208",
"CVE-2025-68214",
"CVE-2025-68235",
"CVE-2025-68259",
"CVE-2025-68261",
"CVE-2025-68264",
"CVE-2025-68265",
"CVE-2025-68297",
"CVE-2025-68309",
"CVE-2025-68331",
"CVE-2025-68337",
"CVE-2025-68349",
"CVE-2025-68354",
"CVE-2025-68356",
"CVE-2025-68362",
"CVE-2025-68363",
"CVE-2025-68376",
"CVE-2025-68378",
"CVE-2025-68724",
"CVE-2025-68725",
"CVE-2025-68734",
"CVE-2025-68741",
"CVE-2025-68744",
"CVE-2025-68745",
"CVE-2025-68756",
"CVE-2025-68780",
"CVE-2025-68782",
"CVE-2025-68794",
"CVE-2025-68803",
"CVE-2025-68814",
"CVE-2025-68816",
"CVE-2025-68817",
"CVE-2025-68818",
"CVE-2025-71072",
"CVE-2025-71077",
"CVE-2025-71104",
"CVE-2025-71116",
"CVE-2025-71131",
"CVE-2025-71134",
"CVE-2025-71147",
"CVE-2025-71149",
"CVE-2025-71150",
"CVE-2025-71152",
"CVE-2025-71154",
"CVE-2025-71238",
"CVE-2026-22978",
"CVE-2026-22980",
"CVE-2026-22990",
"CVE-2026-22992",
"CVE-2026-22996",
"CVE-2026-22998",
"CVE-2026-23000",
"CVE-2026-23005",
"CVE-2026-23035",
"CVE-2026-23060",
"CVE-2026-23069",
"CVE-2026-23071",
"CVE-2026-23086",
"CVE-2026-23099",
"CVE-2026-23103",
"CVE-2026-23105",
"CVE-2026-23111",
"CVE-2026-23120",
"CVE-2026-23124",
"CVE-2026-23126",
"CVE-2026-23133",
"CVE-2026-23136",
"CVE-2026-23137",
"CVE-2026-23138",
"CVE-2026-23139",
"CVE-2026-23145",
"CVE-2026-23154",
"CVE-2026-23156",
"CVE-2026-23169",
"CVE-2026-23173",
"CVE-2026-23191",
"CVE-2026-23198",
"CVE-2026-23204",
"CVE-2026-23208",
"CVE-2026-23212",
"CVE-2026-23221",
"CVE-2026-23230"
]
}
OESA-2026-1761 (CVE-2024-53232)
Vulnerability from osv_openeuler – Published: 2026-03-27 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Implement blocking domain
This fixes a crash when surprise hot-unplugging a PCI device. This crash happens because during hot-unplug __iommu_group_set_domain_nofail() attaching the default domain fails when the platform no longer recognizes the device as it has already been removed and we end up with a NULL domain pointer and UAF. This is exactly the case referred to in the second comment in __iommu_device_set_domain() and just as stated there if we can instead attach the blocking domain the UAF is prevented as this can handle the already removed device. Implement the blocking domain to use this handling. With this change, the crash is fixed but we still hit a warning attempting to change DMA ownership on a blocked device.(CVE-2024-53232)
In the Linux kernel, the following vulnerability has been resolved:
iommu: Fix two issues in iommu_copy_struct_from_user()
In the review for iommu_copy_struct_to_user() helper, Matt pointed out that a NULL pointer should be rejected prior to dereferencing it: https://lore.kernel.org/all/(CVE-2025-37900)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Avoid race in open_cached_dir with lease breaks
A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs.
Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked.(CVE-2025-37954)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: prio: fix a race in prio_tune()
Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 1: lock root
[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.(CVE-2025-38083)
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix potential deadlock in MR deregistration
The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock.
The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | → revoke_mr() | → mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | → mutex_lock(&dev->cache.rb_lock) | → mlx5r_cache_create_ent_locked() | → kzalloc(GFP_KERNEL) | → fs_reclaim() | → mmu_notifier_invalidate_range_start() | → mlx5_ib_invalidate_range() | → mutex_lock(&umem_odp->umem_mutex) → cache_ent_find_and_store() | → mutex_lock(&dev->cache.rb_lock) |
Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex.
Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path.
This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path.
The following lockdep warning demonstrates the deadlock:
python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]
but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138
-> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
-> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core]
---truncated---(CVE-2025-38373)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Harden s32ton() against conversion to 0 bits
Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that.
Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.(CVE-2025-38556)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject narrower access to pointer ctx fields
The following BPF program, simplified from a syzkaller repro, causes a kernel warning:
r0 = *(u8 *)(r1 + 169);
exit;
With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the "is_narrower_load" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning:
verifier bug: error during ctx access conversion(1)
This patch fixes that to return a proper "invalid bpf_context access off=X size=Y" error on the load instruction.
The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency.
Note this syzkaller crash was reported in the "Closes" link below, which used to be about a different bug, fixed in commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.(CVE-2025-38591)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: No more self recovery
When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2_recover_func() will refuse to do anything during a withdraw.
However, before even getting to this point, gfs2_recover_func() dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before commit 04133b607a78 ("gfs2: Prevent double iput for journal on error") and is a NULL pointer dereference since then.
Simply get rid of self recovery to fix that.(CVE-2025-38659)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/net: commit partial buffers on retry
Ring provided buffers are potentially only valid within the single execution context in which they were acquired. io_uring deals with this and invalidates them on retry. But on the networking side, if MSG_WAITALL is set, or if the socket is of the streaming type and too little was processed, then it will hang on to the buffer rather than recycle or commit it. This is problematic for two reasons:
1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid.
2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer.
Fix this by disallowing partial retries from pinning a provided buffer across multiple executions, if ring provided buffers are used.(CVE-2025-38730)
In the Linux kernel, the following vulnerability has been resolved:
media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()
In the interrupt handler rain_interrupt(), the buffer full check on rain->buf_len is performed before acquiring rain->buf_lock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buf_len is concurrently accessed and modified in the work handler rain_irq_work_handler() under the same lock.
Multiple interrupt invocations can race, with each reading buf_len before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buf_len beyond its capacity (DATA_SIZE) and causing a buffer overflow.
Fix this bug by moving the spin_lock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spin_unlock() is added to the overflow path to correctly release the lock.
This possible bug was found by an experimental static analysis tool developed by our team.(CVE-2025-39713)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd/pgtbl: Fix possible race while increase page table level
The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations.
The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level.
But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON.
CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)
Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.(CVE-2025-39961)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: check the return value of pinmux_ops::get_function_name()
While the API contract in docs doesn't specify it explicitly, the generic implementation of the get_function_name() callback from struct pinmux_ops - pinmux_generic_get_function_name() - can fail and return NULL. This is already checked in pinmux_check_ops() so add a similar check in pinmux_func_name_to_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions.(CVE-2025-40030)
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies
When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free.
Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this:
drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; }
for (; i < fence_count; i++)
dma_fence_put(fences[i]);
Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it.
The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").
At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") noticed and attempted to fix.
But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case.
As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain.
While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.(CVE-2025-40096)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete x->tunnel as we delete x
The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.
We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.
Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.
A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.(CVE-2025-40215)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix livelock in synchronous file put from fuseblk workers
I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server:
cat /proc/372265/task/372313/stack
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
But the /weird/ part is that the fuseblk server threads are waiting for responses from itself:
cat /proc/372210/task/372232/stack
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that:
"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands.
Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.(CVE-2025-40220)
In the Linux kernel, the following vulnerability has been resolved:
fs/notify: call exportfs_encode_fid with s_umount
Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr.
This issue was found by syzkaller.
Race Condition Diagram:
Thread 1 Thread 2 -------- --------
generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL
|
| vfs_read()
| inotify_fdinfo()
| * inode get from mark *
| show_mark_fhandle(m, inode)
| exportfs_encode_fid(inode, ..)
| ovl_encode_fh(inode, ..)
| ovl_check_encode_origin(inode)
| * deref i_sb->s_root *
|
|
v
fsnotify_sb_delete(sb)
Which then leads to:
[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)
<snip registers, unreliable trace>
[ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240
IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path.
Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock.
This form of fix was suggested by Amir in 1.
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix unlikely race in gdlm_put_lock
In gdlm_put_lock(), there is a small window of time in which the DFL_UNMOUNT flag has been set but the lockspace hasn't been released, yet. In that window, dlm may still call gdlm_ast() and gdlm_bast(). To prevent it from dereferencing freed glock objects, only free the glock if the lockspace has actually been released.(CVE-2025-40242)
In the Linux kernel, the following vulnerability has been resolved:
devlink: rate: Unset parent pointer in devl_rate_nodes_destroy
The function devl_rate_nodes_destroy is documented to "Unset parent for
all rate objects". However, it was only calling the driver-specific
rate_leaf_parent_set or rate_node_parent_set ops and decrementing
the parent's refcount, without actually setting the
devlink_rate->parent pointer to NULL.
This leaves a dangling pointer in the devlink_rate struct, which cause
refcount error in netdevsim1 and mlx52. In addition, this is
inconsistent with the behavior of devlink_nl_rate_parent_node_set,
where the parent pointer is correctly cleared.
This patch fixes the issue by explicitly setting devlink_rate->parent
to NULL after notifying the driver, thus fulfilling the function's
documented behavior for all rate objects.
1 repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device
dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: <TASK> devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
2 devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core
dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: <TASK> devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-40251)
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |
rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)
In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix use-after-free race in fault handler
When a page fault occurs in a secret memory file created with
memfd_secret(2), the kernel will allocate a new folio for it, mark the
underlying page as not-present in the direct map, and add it to the file
mapping.
If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping.
If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault.
Fix the ordering to restore the direct map before the folio is freed.(CVE-2025-40272)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE
This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.(CVE-2025-40277)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()
In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied.
Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH.
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40294)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: validate skb length for unknown CC opcode
In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory.
The fix is to check skb->len before using skb->data.(CVE-2025-40301)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bcsp: receive data only if registered
Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace:
KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590
Call Trace:
<TASK>
hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627
tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290
tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.(CVE-2025-40308)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and "UAF".
Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.(CVE-2025-40318)
In the Linux kernel, the following vulnerability has been resolved:
futex: Don't leak robust_list pointer on exec race
sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process.
During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged.
A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec().
For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process.
This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk.
Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.(CVE-2025-40341)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: use lock accessing port_state and rport state
nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.(CVE-2025-40342)
In the Linux kernel, the following vulnerability has been resolved:
nvmet-fc: avoid scheduling association deletion twice
When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion.
The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion.
Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.(CVE-2025-40343)
In the Linux kernel, the following vulnerability has been resolved:
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
The syzbot reported issue in hfsplus_delete_cat():
[ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] slaballoc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] ---truncated---(CVE-2025-40351)
In the Linux kernel, the following vulnerability has been resolved:
riscv: stacktrace: Disable KASAN checks for non-current tasks
Unwinding the stack of a task other than current, KASAN would report "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"
There is a same issue on x86 and has been resolved by the commit 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks") The solution could be applied to RISC-V too.
This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23
[(CVE-2025-40358)
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Fix KASAN global-out-of-bounds warning
When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen.
================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850
Call Trace:
kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80
The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF.
WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)
So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue.(CVE-2025-40359)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-40361)
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Ensure XFD state on signal delivery
Sean reported 1 the following splat when running KVM tests:
WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Chao further identified 2 a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR.
When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption.
Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature.
This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible.
dhansen: minor changelog munging
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix softlockup in ftrace_module_enable
A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()").
Fix it the same way by adding cond_resched() in ftrace_module_enable.(CVE-2025-68173)
In the Linux kernel, the following vulnerability has been resolved:
amd/amdkfd: enhance kfd process check in switch partition
current switch partition only check if kfd_processes_table is empty. kfd_prcesses_table entry is deleted in kfd_process_notifier_release, but kfd_process tear down is in kfd_process_wq_release.
consider two processes:
Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node member Process B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw -> kfd_node tear down.
Process A and B may trigger a race as shown in dmesg log.
This patch is to resolve the race by adding an atomic kfd_process counter kfd_processes_count, it increment as create kfd process, decrement as finish kfd_process_wq_release.
v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds and bug fix. (Philip Yang)
[3966658.307702] divide error: 0000 [#1] SMP NOPTI [3966658.350818] i10nm_edac [3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted [3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] [3966658.362839] nfit [3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu] [3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 <f7> be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00 [3966658.380967] x86_pkg_temp_thermal [3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246 [3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000 [3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00 [3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4 [3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000 [3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800 [3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000 [3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0 [3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [3966658.391536] PKRU: 55555554 [3966658.391536] Call Trace: [3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu] [3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu] [3966658.399754] intel_powerclamp [3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu] [3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu] [3966658.410516] coretemp [3966658.434016] process_one_work+0x1ad/0x380 [3966658.434021] worker_thread+0x49/0x310 [3966658.438963] kvm_intel [3966658.446041] ? process_one_work+0x380/0x380 [3966658.446045] kthread+0x118/0x140 [3966658.446047] ? __kthread_bind_mask+0x60/0x60 [3966658.446050] ret_from_fork+0x1f/0x30 [3966658.446053] Modules linked in: kpatch_20765354(OEK) [3966658.455310] kvm [3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK) [3966658.473462] idxd_mdev [3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo ---truncated---(CVE-2025-68174)
In the Linux kernel, the following vulnerability has been resolved:
PCI: cadence: Check for the existence of cdns_pcie::ops before using it
cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops.
Hence, add a check to prevent NULL pointer dereference.
mani: reworded subject and description
In the Linux kernel, the following vulnerability has been resolved:
tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()
Use RCU to avoid a pair of atomic operations and a potential UAF on dst_dev()->flags.(CVE-2025-68188)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Add bpf_prog_run_data_pointers()
syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().
WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214
struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and data_end for cls_act_bpf").
drop_reason was added later.
Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end.(CVE-2025-68200)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: add seqadj extension for natted connections
Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq.
The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet }
chain prerouting {
type filter hook prerouting priority 0; policy accept;
tcp dport 21 ct state new ct helper set "ftp_helper"
}
} table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } }
chain postrouting {
type nat hook postrouting priority 100 ; policy accept;
tcp sport 21 snat ip prefix to ip saddr map {
192.168.13.2 : 192.168.100.1/32 }
}
}
Note that the ftp helper gets assigned after the dnat setup.
The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem.
Topoloy:
+-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+
ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection.
Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..
Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.(CVE-2025-68206)
In the Linux kernel, the following vulnerability has been resolved:
bpf: account for current allocated stack depth in widen_imprecise_scalars()
The usage pattern for widen_imprecise_scalars() looks as follows:
prev_st = find_prev_entry(env, ...);
queued_st = push_stack(...);
widen_imprecise_scalars(env, prev_st, queued_st);
Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case:
def main():
for i in 1..2:
foo(i) // same callsite, differnt param
def foo(i):
if i == 1:
use 128 bytes of stack
iterator based loop
Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds.(CVE-2025-68208)
In the Linux kernel, the following vulnerability has been resolved:
nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot
nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning.
Make sure this data is deallocated.(CVE-2025-68235)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced
When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn instruction, discard the exception and retry the instruction if the code stream is changed (e.g. by a different vCPU) between when the CPU executes the instruction and when KVM decodes the instruction to get the next RIP.
As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction"), failure to verify that the correct INTn instruction was decoded can effectively clobber guest state due to decoding the wrong instruction and thus specifying the wrong next RIP.
The bug most often manifests as "Oops: int3" panics on static branch checks in Linux guests. Enabling or disabling a static branch in Linux uses the kernel's "text poke" code patching mechanism. To modify code while other CPUs may be executing that code, Linux (temporarily) replaces the first byte of the original instruction with an int3 (opcode 0xcc), then patches in the new code stream except for the first byte, and finally replaces the int3 with the first byte of the new code stream. If a CPU hits the int3, i.e. executes the code while it's being modified, then the guest kernel must look up the RIP to determine how to handle the #BP, e.g. by emulating the new instruction. If the RIP is incorrect, then this lookup fails and the guest kernel panics.
The bug reproduces almost instantly by hacking the guest kernel to repeatedly check a static branch1 while running a drgn script2 on the host to constantly swap out the memory containing the guest's TSS.
In the Linux kernel, the following vulnerability has been resolved:
ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()
Fix a race between inline data destruction and block mapping.
The function ext4_destroy_inline_data_nolock() changes the inode data layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS. At the same time, another thread may execute ext4_map_blocks(), which tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks() or ext4_ind_map_blocks().
Without i_data_sem protection, ext4_ind_map_blocks() may receive inode with EXT4_INODE_EXTENTS flag and triggering assert.
kernel BUG at fs/ext4/indirect.c:546! EXT4-fs (loop2): unmounting filesystem. invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546
Call Trace: <TASK> ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2025-68261)
In the Linux kernel, the following vulnerability has been resolved:
ext4: refresh inline data size before write operations
The cached ei->i_inline_size can become stale between the initial size check and when ext4_update_inline_data()/ext4_create_inline_data() use it. Although ext4_get_max_inline_size() reads the correct value at the time of the check, concurrent xattr operations can modify i_inline_size before ext4_write_lock_xattr() is acquired.
This causes ext4_update_inline_data() and ext4_create_inline_data() to work with stale capacity values, leading to a BUG_ON() crash in ext4_write_inline_data():
kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
The race window: 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, i_inline_size changes to 40] 4. ext4_write_lock_xattr() acquires lock 5. ext4_update_inline_data() uses stale i_inline_size = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers
Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock() immediately after acquiring xattr_sem. This ensures ext4_update_inline_data() and ext4_create_inline_data() work with current values that are protected from concurrent modifications.
This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inline_data file while its xattrs are changing") which fixed i_inline_off staleness. This patch addresses the related i_inline_size staleness issue.(CVE-2025-68264)
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix admin request_queue lifetime
The namespaces can access the controller's admin request_queue, and stale references on the namespaces may exist after tearing down the controller. Ensure the admin request_queue is active by moving the controller's 'put' to after all controller references have been released to ensure no one is can access the request_queue. This fixes a reported use-after-free bug:
BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNED_MODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: <TASK> dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ? _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 ? blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 ? wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0 ? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 ? cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380 __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60 </TASK>(CVE-2025-68265)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix crash in process_v2_sparse_read() for encrypted directories
The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps:
sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure
(1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered
[ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] <TASK> [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] </TASK> [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---(CVE-2025-68297)
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: fix fragment overflow handling in RX path
The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.
The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.
Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path.
This crash occurred in production with an Aquantia AQC113 10G NIC.
Stack trace from production environment:
RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0
Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89
ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90
c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48
89 fa 83
RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287
RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:
fffffffe0a0c8000
RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:
0000000000037a40
RBP: 0000000000000024 R08: 0000000000000000 R09:
0000000000000021
R10: 0000000000000848 R11: 0000000000000000 R12:
ffffa9bec02a8e24
R13: ffff925ad8615570 R14: 0000000000000000 R15:
ffff925b22e80a00
FS: 0000000000000000(0000)
GS:ffff925e47880000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:
0000000000f72ef0
PKRU: 55555554
Call Trace:
<IRQ>
aq_ring_rx_clean+0x175/0xe60 [atlantic]
? aq_ring_rx_clean+0x14d/0xe60 [atlantic]
? aq_ring_tx_clean+0xdf/0x190 [atlantic]
? kmem_cache_free+0x348/0x450
? aq_vec_poll+0x81/0x1d0 [atlantic]
? __napi_poll+0x28/0x1c0
? net_rx_action+0x337/0x420
Changes in v4: - Add Fixes: tag to satisfy patch validation requirements.
Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.(CVE-2025-68301)
In the Linux kernel, the following vulnerability has been resolved:
PCI/AER: Fix NULL pointer access by aer_info
The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info->xxx will result in kernel panic. Fix it.(CVE-2025-68309)
In the Linux kernel, the following vulnerability has been resolved:
usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer
When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed.
The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed.
This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs().
The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().(CVE-2025-68331)
In the Linux kernel, the following vulnerability has been resolved:
jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted
There's issue when file system corrupted: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1289! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0 RSP: 0018:ffff888117aafa30 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534 RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010 RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028 R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0 Call Trace: <TASK> __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The above issue occurs with us in errors=continue mode when accompanied by storage failures. There have been many inconsistencies in the file system data. In the case of file system data inconsistency, for example, if the block bitmap of a referenced block is not set, it can lead to the situation where a block being committed is allocated and used again. As a result, the following condition will not be satisfied then trigger BUG_ON. Of course, it is entirely possible to construct a problematic image that can trigger this BUG_ON through specific operations. In fact, I have constructed such an image and easily reproduced this issue. Therefore, J_ASSERT() holds true only under ideal conditions, but it may not necessarily be satisfied in exceptional scenarios. Using J_ASSERT() directly in abnormal situations would cause the system to crash, which is clearly not what we want. So here we directly trigger a JBD abort instead of immediately invoking BUG_ON.(CVE-2025-68337)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid
Fixes a crash when layout is null during this call stack:
write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode
pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.(CVE-2025-68349)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to:
1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.
Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Prevent recursive memory reclaim
Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory.
Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue.
To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS.
The "meta" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt.
This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation").
Fixes xfstest generic/273.(CVE-2025-68356)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()
The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header.
If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic.
Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.(CVE-2025-68362)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check skb->transport_header is set in bpf_skb_check_mtu
The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used:
bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)
The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used:
WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb
For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").
This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.(CVE-2025-68363)
In the Linux kernel, the following vulnerability has been resolved:
coresight: ETR: Fix ETR buffer use-after-free issue
When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue.
Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.(CVE-2025-68376)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stackmap overflow check in __bpf_get_stackid()
Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.(CVE-2025-68378)
In the Linux kernel, the following vulnerability has been resolved:
crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id
Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.(CVE-2025-68724)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do not let BPF test infra emit invalid GSO types to stack
Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled.
We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place.
The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.(CVE-2025-68725)
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()
In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style.
Compile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix improper freeing of purex item
In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item().
The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc().
An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption.
Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.(CVE-2025-68741)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Free special fields when update [lru_,]percpu_hash maps
As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed.
Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value,_long' in 'pcpu_copy_value()'.(CVE-2025-68744)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Clear cmds after chip reset
Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems:
-
Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.
-
BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().
So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at __qla2x00_abort_all_cmds.(CVE-2025-68745)
In the Linux kernel, the following vulnerability has been resolved:
block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock
blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared.
Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also.
This results in deadlock between two threads with these stacktraces:
__schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20
__schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53
The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list.
The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever.
Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.(CVE-2025-68756)
In the Linux kernel, the following vulnerability has been resolved:
sched/deadline: only set free_cpus for online runqueues
Commit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpus to reflect rd->online") introduced the cpudl_set/clear_freecpu functions to allow the cpu_dl::free_cpus mask to be manipulated by the deadline scheduler class rq_on/offline callbacks so the mask would also reflect this state.
Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_mask from cpudl_find()") removed the check of the cpu_active_mask to save some processing on the premise that the cpudl::free_cpus mask already reflected the runqueue online state.
Unfortunately, there are cases where it is possible for the cpudl_clear function to set the free_cpus bit for a CPU when the deadline runqueue is offline. When this occurs while a CPU is connected to the default root domain the flag may retain the bad state after the CPU has been unplugged. Later, a different CPU that is transitioning through the default root domain may push a deadline task to the powered down CPU when cpudl_find sees its free_cpus bit is set. If this happens the task will not have the opportunity to run.
One example is outlined here: https://lore.kernel.org/lkml/(CVE-2025-68780)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: Reset t_task_cdb pointer in error case
If allocation of cmd->t_task_cdb fails, it remains NULL but is later dereferenced in the 'err' path.
In case of error, reset NULL t_task_cdb value to point at the default fixed-size buffer.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68782)
In the Linux kernel, the following vulnerability has been resolved:
iomap: adjust read range correctly for non-block-aligned positions
iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio.
Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.(CVE-2025-68794)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: NFSv4 file creation neglects setting ACL
An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: "the ACL attribute is set as given".
The issue occurs in nfsd_create_setattr(), which calls nfsd_attrs_valid() to determine whether to call nfsd_setattr(). However, nfsd_attrs_valid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsd_setattr() is skipped, and the POSIX ACL is never applied to the inode.
Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL.(CVE-2025-68803)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix filename leak in __io_openat_prep()
__io_openat_prep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak.
Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup.(CVE-2025-68814)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: fw_tracer, Validate format string parameters
Add validation for format string parameters in the firmware tracer to prevent potential security vulnerabilities and crashes from malformed format strings received from firmware.
The firmware tracer receives format strings from the device firmware and uses them to format trace messages. Without proper validation, bad firmware could provide format strings with invalid format specifiers (e.g., %s, %p, %n) that could lead to crashes, or other undefined behavior.
Add mlx5_tracer_validate_params() to validate that all format specifiers in trace strings are limited to safe integer/hex formats (%x, %d, %i, %u, %llx, %lx, etc.). Reject strings containing other format types that could be used to access arbitrary memory or cause crashes. Invalid format strings are added to the trace output for visibility with "BAD_FORMAT: " prefix.(CVE-2025-68816)
In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"
This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.
The commit being reverted added code to __qla2x00_abort_all_cmds() to call sp->done() without holding a spinlock. But unlike the older code below it, this new code failed to check sp->cmd_type and just assumed TYPE_SRB, which results in a jump to an invalid pointer in target-mode with TYPE_TGT_CMD:
qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79b qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h. qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no buffer qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurred qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda. BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor instruction fetch in kernel mode PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1 Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206 RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000 RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0 RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045 R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40 R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400 FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 </TASK>
Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early within lock") added the spinlock back, because not having the lock caused a race and a crash. But qla2x00_abort_srb() in the switch below already checks for qla2x00_chip_is_down() and handles it the same way, so the code above the switch is now redundant and still buggy in target-mode. Remove it.(CVE-2025-68818)
In the Linux kernel, the following vulnerability has been resolved:
shmem: fix recovery on rename failures
maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange().
Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout().
Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton.
For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations.
For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations.
That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().(CVE-2025-71072)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in update_target_expiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 </IRQ>
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---(CVE-2025-71104)
In the Linux kernel, the following vulnerability has been resolved:
libceph: make decode_pool() more resilient against corrupted osdmaps
If the osdmap is (maliciously) corrupted such that the encoded length of ceph_pg_pool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value.
This patch adds explicit bounds checks for each field that is decoded or skipped.(CVE-2025-71116)
In the Linux kernel, the following vulnerability has been resolved:
crypto: seqiv - Do not use req->iv after crypto_aead_encrypt
As soon as crypto_aead_encrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.
Instead of checking req->iv against info, create a new variable unaligned_info and use it for that purpose instead.(CVE-2025-71131)
In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix a memory leak in tpm2_load_cmd
'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode' but it is not freed in the failure paths. Address this by wrapping the blob into with a cleanup helper.(CVE-2025-71147)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: correctly handle io_poll_add() return value on update
When the core of io_uring was updated to handle completions consistently and with fixed return codes, the POLL_REMOVE opcode with updates got slightly broken. If a POLL_ADD is pending and then POLL_REMOVE is used to update the events of that request, if that update causes the POLL_ADD to now trigger, then that completion is lost and a CQE is never posted.
Additionally, ensure that if an update does cause an existing POLL_ADD to complete, that the completion value isn't always overwritten with -ECANCELED. For that case, whatever io_poll_add() set the value to should just be retained.(CVE-2025-71149)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Fix refcount leak when invalid session is found on session lookup
When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.(CVE-2025-71150)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv
mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5e_dev and get mdev from the containing mlx5_adev aux device structure.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_remove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: <TASK> device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-22996)
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec
Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs.
The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.
Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL
The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated(CVE-2026-22998)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix crash on profile change rollback failure
mlx5e_netdev_change_profile can fail to attach a new profile and can fail to rollback to old profile, in such case, we could end up with a dangling netdev with a fully reset netdev_priv. A retry to change profile, e.g. another attempt to call mlx5e_netdev_change_profile via switchdev mode change, will crash trying to access the now NULL priv->mdev.
This fix allows mlx5e_netdev_change_profile() to handle previous failures and an empty priv, by not assuming priv is valid.
Pass netdev and mdev to all flows requiring mlx5e_netdev_change_profile() and avoid passing priv. In mlx5e_netdev_change_profile() check if current priv is valid, and if not, just attach the new profile without trying to access the old one.
This fixes the following oops, when enabling switchdev mode for the 2nd time after first time failure:
## Enabling switchdev mode first time:
mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 ^^^^^^^^ mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)
## retry: Enabling switchdev mode 2nd time:
mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload BUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_detach_netdev+0x3c/0x90 Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdfb8495047(CVE-2026-23000)
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1
When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel.
E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:
------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's call to fpu_update_guest_xfd().
and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:
------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component):
If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).
Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD.
Therefore, XFD can only go out of sync with XSTATE_BV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.
[Move clea ---truncated---(CVE-2026-23005)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv
mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails.
Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a valid netdev.
On mlx5e_remove: Check validity of priv->profile, before attempting to cleanup any resources that might be not there.
This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0 RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10 R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0 R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400 FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-23035)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add recursion protection in kernel stack trace recording
A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again.
Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI).
Have the stack trace code use the interrupt context to protect against recursion.
Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately.(CVE-2026-23138)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"perf-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-144.0.0.140.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-144.0.0.140.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"perf-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-144.0.0.140.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-144.0.0.140.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-144.0.0.140.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\niommu/s390: Implement blocking domain\n\nThis fixes a crash when surprise hot-unplugging a PCI device. This crash\nhappens because during hot-unplug __iommu_group_set_domain_nofail()\nattaching the default domain fails when the platform no longer\nrecognizes the device as it has already been removed and we end up with\na NULL domain pointer and UAF. This is exactly the case referred to in\nthe second comment in __iommu_device_set_domain() and just as stated\nthere if we can instead attach the blocking domain the UAF is prevented\nas this can handle the already removed device. Implement the blocking\ndomain to use this handling. With this change, the crash is fixed but\nwe still hit a warning attempting to change DMA ownership on a blocked\ndevice.(CVE-2024-53232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu: Fix two issues in iommu_copy_struct_from_user()\n\nIn the review for iommu_copy_struct_to_user() helper, Matt pointed out that\na NULL pointer should be rejected prior to dereferencing it:\nhttps://lore.kernel.org/all/(CVE-2025-37900)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Avoid race in open_cached_dir with lease breaks\n\nA pre-existing valid cfid returned from find_or_create_cached_dir might\nrace with a lease break, meaning open_cached_dir doesn\u0026apos;t consider it\nvalid, and thinks it\u0026apos;s newly-constructed. This leaks a dentry reference\nif the allocation occurs before the queued lease break work runs.\n\nAvoid the race by extending holding the cfid_list_lock across\nfind_or_create_cached_dir and when the result is checked.(CVE-2025-37954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: prio: fix a race in prio_tune()\n\nGerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n | [5]: lock root\n | [6]: rehash\n | [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent\u0026apos;s qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.(CVE-2025-38083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix potential deadlock in MR deregistration\n\nThe issue arises when kzalloc() is invoked while holding umem_mutex or\nany other lock acquired under umem_mutex. This is problematic because\nkzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke\nmmu_notifier_invalidate_range_start(). This function can lead to\nmlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,\nresulting in a deadlock.\n\nThe problematic flow:\n CPU0 | CPU1\n---------------------------------------|------------------------------------------------\nmlx5_ib_dereg_mr() |\n \u2192 revoke_mr() |\n \u2192 mutex_lock(\u0026amp;umem_odp-\u0026gt;umem_mutex) |\n | mlx5_mkey_cache_init()\n | \u2192 mutex_lock(\u0026amp;dev-\u0026gt;cache.rb_lock)\n | \u2192 mlx5r_cache_create_ent_locked()\n | \u2192 kzalloc(GFP_KERNEL)\n | \u2192 fs_reclaim()\n | \u2192 mmu_notifier_invalidate_range_start()\n | \u2192 mlx5_ib_invalidate_range()\n | \u2192 mutex_lock(\u0026amp;umem_odp-\u0026gt;umem_mutex)\n \u2192 cache_ent_find_and_store() |\n \u2192 mutex_lock(\u0026amp;dev-\u0026gt;cache.rb_lock) |\n\nAdditionally, when kzalloc() is called from within\ncache_ent_find_and_store(), we encounter the same deadlock due to\nre-acquisition of umem_mutex.\n\nSolve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()\nand before acquiring rb_lock. This ensures that we don\u0026apos;t hold\numem_mutex while performing memory allocations that could trigger\nthe reclaim path.\n\nThis change prevents the deadlock by ensuring proper lock ordering and\navoiding holding locks during memory allocation operations that could\ntrigger the reclaim path.\n\nThe following lockdep warning demonstrates the deadlock:\n\n python3/20557 is trying to acquire lock:\n ffff888387542128 (\u0026amp;umem_odp-\u0026gt;umem_mutex){+.+.}-{4:4}, at:\n mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]\n\n but task is already holding lock:\n ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:\n unmap_vmas+0x7b/0x1a0\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u0026gt; #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:\n fs_reclaim_acquire+0x60/0xd0\n mem_cgroup_css_alloc+0x6f/0x9b0\n cgroup_init_subsys+0xa4/0x240\n cgroup_init+0x1c8/0x510\n start_kernel+0x747/0x760\n x86_64_start_reservations+0x25/0x30\n x86_64_start_kernel+0x73/0x80\n common_startup_64+0x129/0x138\n\n -\u0026gt; #2 (fs_reclaim){+.+.}-{0:0}:\n fs_reclaim_acquire+0x91/0xd0\n __kmalloc_cache_noprof+0x4d/0x4c0\n mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]\n mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]\n mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]\n __mlx5_ib_add+0x4b/0x190 [mlx5_ib]\n mlx5r_probe+0xd9/0x320 [mlx5_ib]\n auxiliary_bus_probe+0x42/0x70\n really_probe+0xdb/0x360\n __driver_probe_device+0x8f/0x130\n driver_probe_device+0x1f/0xb0\n __driver_attach+0xd4/0x1f0\n bus_for_each_dev+0x79/0xd0\n bus_add_driver+0xf0/0x200\n driver_register+0x6e/0xc0\n __auxiliary_driver_register+0x6a/0xc0\n do_one_initcall+0x5e/0x390\n do_init_module+0x88/0x240\n init_module_from_file+0x85/0xc0\n idempotent_init_module+0x104/0x300\n __x64_sys_finit_module+0x68/0xc0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n -\u0026gt; #1 (\u0026amp;dev-\u0026gt;cache.rb_lock){+.+.}-{4:4}:\n __mutex_lock+0x98/0xf10\n __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]\n mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]\n ib_dereg_mr_user+0x85/0x1f0 [ib_core]\n \n---truncated---(CVE-2025-38373)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Harden s32ton() against conversion to 0 bits\n\nTesting by the syzbot fuzzer showed that the HID core gets a\nshift-out-of-bounds exception when it tries to convert a 32-bit\nquantity to a 0-bit quantity. Ideally this should never occur, but\nthere are buggy devices and some might have a report field with size\nset to zero; we shouldn\u0026apos;t reject the report or the device just because\nof that.\n\nInstead, harden the s32ton() routine so that it returns a reasonable\nresult instead of crashing when it is called with the number of bits\nset to 0 -- the same as what snto32() does.(CVE-2025-38556)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject narrower access to pointer ctx fields\n\nThe following BPF program, simplified from a syzkaller repro, causes a\nkernel warning:\n\n r0 = *(u8 *)(r1 + 169);\n exit;\n\nWith pointer field sk being at offset 168 in __sk_buff. This access is\ndetected as a narrower read in bpf_skb_is_valid_access because it\ndoesn\u0026apos;t match offsetof(struct __sk_buff, sk). It is therefore allowed\nand later proceeds to bpf_convert_ctx_access. Note that for the\n\u0026quot;is_narrower_load\u0026quot; case in the convert_ctx_accesses(), the insn-\u0026gt;off\nis aligned, so the cnt may not be 0 because it matches the\noffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,\nthe target_size stays 0 and the verifier errors with a kernel warning:\n\n verifier bug: error during ctx access conversion(1)\n\nThis patch fixes that to return a proper \u0026quot;invalid bpf_context access\noff=X size=Y\u0026quot; error on the load instruction.\n\nThe same issue affects multiple other fields in context structures that\nallow narrow access. Some other non-affected fields (for sk_msg,\nsk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for\nconsistency.\n\nNote this syzkaller crash was reported in the \u0026quot;Closes\u0026quot; link below, which\nused to be about a different bug, fixed in\ncommit fce7bd8e385a (\u0026quot;bpf/verifier: Handle BPF_LOAD_ACQ instructions\nin insn_def_regno()\u0026quot;). Because syzbot somehow confused the two bugs,\nthe new crash and repro didn\u0026apos;t get reported to the mailing list.(CVE-2025-38591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: No more self recovery\n\nWhen a node withdraws and it turns out that it is the only node that has\nthe filesystem mounted, gfs2 currently tries to replay the local journal\nto bring the filesystem back into a consistent state. Not only is that\na very bad idea, it has also never worked because gfs2_recover_func()\nwill refuse to do anything during a withdraw.\n\nHowever, before even getting to this point, gfs2_recover_func()\ndereferences sdp-\u0026gt;sd_jdesc-\u0026gt;jd_inode. This was a use-after-free before\ncommit 04133b607a78 (\u0026quot;gfs2: Prevent double iput for journal on error\u0026quot;)\nand is a NULL pointer dereference since then.\n\nSimply get rid of self recovery to fix that.(CVE-2025-38659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/net: commit partial buffers on retry\n\nRing provided buffers are potentially only valid within the single\nexecution context in which they were acquired. io_uring deals with this\nand invalidates them on retry. But on the networking side, if\nMSG_WAITALL is set, or if the socket is of the streaming type and too\nlittle was processed, then it will hang on to the buffer rather than\nrecycle or commit it. This is problematic for two reasons:\n\n1) If someone unregisters the provided buffer ring before a later retry,\n then the req-\u0026gt;buf_list will no longer be valid.\n\n2) If multiple sockers are using the same buffer group, then multiple\n receives can consume the same memory. This can cause data corruption\n in the application, as either receive could land in the same\n userspace buffer.\n\nFix this by disallowing partial retries from pinning a provided buffer\nacross multiple executions, if ring provided buffers are used.(CVE-2025-38730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()\n\nIn the interrupt handler rain_interrupt(), the buffer full check on\nrain-\u0026gt;buf_len is performed before acquiring rain-\u0026gt;buf_lock. This\ncreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as\nrain-\u0026gt;buf_len is concurrently accessed and modified in the work\nhandler rain_irq_work_handler() under the same lock.\n\nMultiple interrupt invocations can race, with each reading buf_len\nbefore it becomes full and then proceeding. This can lead to both\ninterrupts attempting to write to the buffer, incrementing buf_len\nbeyond its capacity (DATA_SIZE) and causing a buffer overflow.\n\nFix this bug by moving the spin_lock() to before the buffer full\ncheck. This ensures that the check and the subsequent buffer modification\nare performed atomically, preventing the race condition. An corresponding\nspin_unlock() is added to the overflow path to correctly release the\nlock.\n\nThis possible bug was found by an experimental static analysis tool\ndeveloped by our team.(CVE-2025-39713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/pgtbl: Fix possible race while increase page table level\n\nThe AMD IOMMU host page table implementation supports dynamic page table levels\n(up to 6 levels), starting with a 3-level configuration that expands based on\nIOVA address. The kernel maintains a root pointer and current page table level\nto enable proper page table walks in alloc_pte()/fetch_pte() operations.\n\nThe IOMMU IOVA allocator initially starts with 32-bit address and onces its\nexhuasted it switches to 64-bit address (max address is determined based\non IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU\ndriver increases page table level.\n\nBut in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads\npgtable-\u0026gt;[root/mode] without lock. So its possible that in exteme corner case,\nwhen increase_address_space() is updating pgtable-\u0026gt;[root/mode], fetch_pte()\nreads wrong page table level (pgtable-\u0026gt;mode). It does compare the value with\nlevel encoded in page table and returns NULL. This will result is\niommu_unmap ops to fail and upper layer may retry/log WARN_ON.\n\nCPU 0 CPU 1\n------ ------\nmap pages unmap pages\nalloc_pte() -\u0026gt; increase_address_space() iommu_v1_unmap_pages() -\u0026gt; fetch_pte()\n pgtable-\u0026gt;root = pte (new root value)\n READ pgtable-\u0026gt;[mode/root]\n\t\t\t\t\t Reads new root, old mode\n Updates mode (pgtable-\u0026gt;mode += 1)\n\nSince Page table level updates are infrequent and already synchronized with a\nspinlock, implement seqcount to enable lock-free read operations on the read path.(CVE-2025-39961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: check the return value of pinmux_ops::get_function_name()\n\nWhile the API contract in docs doesn\u0026apos;t specify it explicitly, the\ngeneric implementation of the get_function_name() callback from struct\npinmux_ops - pinmux_generic_get_function_name() - can fail and return\nNULL. This is already checked in pinmux_check_ops() so add a similar\ncheck in pinmux_func_name_to_selector() instead of passing the returned\npointer right down to strcmp() where the NULL can get dereferenced. This\nis normal operation when adding new pinfunctions.(CVE-2025-40030)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies\n\nWhen adding dependencies with drm_sched_job_add_dependency(), that\nfunction consumes the fence reference both on success and failure, so in\nthe latter case the dma_fence_put() on the error path (xarray failed to\nexpand) is a double free.\n\nInterestingly this bug appears to have been present ever since\ncommit ebd5f74255b9 (\u0026quot;drm/sched: Add dependency tracking\u0026quot;), since the code\nback then looked like this:\n\ndrm_sched_job_add_implicit_dependencies():\n...\n for (i = 0; i \u0026lt; fence_count; i++) {\n ret = drm_sched_job_add_dependency(job, fences[i]);\n if (ret)\n break;\n }\n\n for (; i \u0026lt; fence_count; i++)\n dma_fence_put(fences[i]);\n\nWhich means for the failing \u0026apos;i\u0026apos; the dma_fence_put was already a double\nfree. Possibly there were no users at that time, or the test cases were\ninsufficient to hit it.\n\nThe bug was then only noticed and fixed after\ncommit 9c2ba265352a (\u0026quot;drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2\u0026quot;)\nlanded, with its fixup of\ncommit 4eaf02d6076c (\u0026quot;drm/scheduler: fix drm_sched_job_add_implicit_dependencies\u0026quot;).\n\nAt that point it was a slightly different flavour of a double free, which\ncommit 963d0b356935 (\u0026quot;drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder\u0026quot;)\nnoticed and attempted to fix.\n\nBut it only moved the double free from happening inside the\ndrm_sched_job_add_dependency(), when releasing the reference not yet\nobtained, to the caller, when releasing the reference already released by\nthe former in the failure case.\n\nAs such it is not easy to identify the right target for the fixes tag so\nlets keep it simple and just continue the chain.\n\nWhile fixing we also improve the comment and explain the reason for taking\nthe reference and not dropping it.(CVE-2025-40096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete x-\u0026gt;tunnel as we delete x\n\nThe ipcomp fallback tunnels currently get deleted (from the various\nlists and hashtables) as the last user state that needed that fallback\nis destroyed (not deleted). If a reference to that user state still\nexists, the fallback state will remain on the hashtables/lists,\ntriggering the WARN in xfrm_state_fini. Because of those remaining\nreferences, the fix in commit f75a2804da39 (\u0026quot;xfrm: destroy xfrm_state\nsynchronously on net exit path\u0026quot;) is not complete.\n\nWe recently fixed one such situation in TCP due to defered freeing of\nskbs (commit 9b6412e6979f (\u0026quot;tcp: drop secpath at the same time as we\ncurrently drop dst\u0026quot;)). This can also happen due to IP reassembly: skbs\nwith a secpath remain on the reassembly queue until netns\ndestruction. If we can\u0026apos;t guarantee that the queues are flushed by the\ntime xfrm_state_fini runs, there may still be references to a (user)\nxfrm_state, preventing the timely deletion of the corresponding\nfallback state.\n\nInstead of chasing each instance of skbs holding a secpath one by one,\nthis patch fixes the issue directly within xfrm, by deleting the\nfallback state as soon as the last user state depending on it has been\ndeleted. Destruction will still happen when the final reference is\ndropped.\n\nA separate lockdep class for the fallback state is required since\nwe\u0026apos;re going to lock x-\u0026gt;tunnel while x is locked.(CVE-2025-40215)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix livelock in synchronous file put from fuseblk workers\n\nI observed a hang when running generic/323 against a fuseblk server.\nThis test opens a file, initiates a lot of AIO writes to that file\ndescriptor, and closes the file descriptor before the writes complete.\nUnsurprisingly, the AIO exerciser threads are mostly stuck waiting for\nresponses from the fuseblk server:\n\n# cat /proc/372265/task/372313/stack\n[\u0026lt;0\u0026gt;] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u0026lt;0\u0026gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_do_getattr+0xfc/0x1f0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_file_read_iter+0xbe/0x1c0 [fuse]\n[\u0026lt;0\u0026gt;] aio_read+0x130/0x1e0\n[\u0026lt;0\u0026gt;] io_submit_one+0x542/0x860\n[\u0026lt;0\u0026gt;] __x64_sys_io_submit+0x98/0x1a0\n[\u0026lt;0\u0026gt;] do_syscall_64+0x37/0xf0\n[\u0026lt;0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nBut the /weird/ part is that the fuseblk server threads are waiting for\nresponses from itself:\n\n# cat /proc/372210/task/372232/stack\n[\u0026lt;0\u0026gt;] request_wait_answer+0x1fe/0x2a0 [fuse]\n[\u0026lt;0\u0026gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_file_put+0x9a/0xd0 [fuse]\n[\u0026lt;0\u0026gt;] fuse_release+0x36/0x50 [fuse]\n[\u0026lt;0\u0026gt;] __fput+0xec/0x2b0\n[\u0026lt;0\u0026gt;] task_work_run+0x55/0x90\n[\u0026lt;0\u0026gt;] syscall_exit_to_user_mode+0xe9/0x100\n[\u0026lt;0\u0026gt;] do_syscall_64+0x43/0xf0\n[\u0026lt;0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe fuseblk server is fuse2fs so there\u0026apos;s nothing all that exciting in\nthe server itself. So why is the fuse server calling fuse_file_put?\nThe commit message for the fstest sheds some light on that:\n\n\u0026quot;By closing the file descriptor before calling io_destroy, you pretty\nmuch guarantee that the last put on the ioctx will be done in interrupt\ncontext (during I/O completion).\n\nAha. AIO fgets a new struct file from the fd when it queues the ioctx.\nThe completion of the FUSE_WRITE command from userspace causes the fuse\nserver to call the AIO completion function. The completion puts the\nstruct file, queuing a delayed fput to the fuse server task. When the\nfuse server task returns to userspace, it has to run the delayed fput,\nwhich in the case of a fuseblk server, it does synchronously.\n\nSending the FUSE_RELEASE command sychronously from fuse server threads\nis a bad idea because a client program can initiate enough simultaneous\nAIOs such that all the fuse server threads end up in delayed_fput, and\nnow there aren\u0026apos;t any threads left to handle the queued fuse commands.\n\nFix this by only using asynchronous fputs when closing files, and leave\na comment explaining why.(CVE-2025-40220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/notify: call exportfs_encode_fid with s_umount\n\nCalling intotify_show_fdinfo() on fd watching an overlayfs inode, while\nthe overlayfs is being unmounted, can lead to dereferencing NULL ptr.\n\nThis issue was found by syzkaller.\n\nRace Condition Diagram:\n\nThread 1 Thread 2\n-------- --------\n\ngeneric_shutdown_super()\n shrink_dcache_for_umount\n sb-\u0026gt;s_root = NULL\n\n |\n | vfs_read()\n | inotify_fdinfo()\n | * inode get from mark *\n | show_mark_fhandle(m, inode)\n | exportfs_encode_fid(inode, ..)\n | ovl_encode_fh(inode, ..)\n | ovl_check_encode_origin(inode)\n | * deref i_sb-\u0026gt;s_root *\n |\n |\n v\n fsnotify_sb_delete(sb)\n\nWhich then leads to:\n\n[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)\n\n\u0026lt;snip registers, unreliable trace\u0026gt;\n\n[ 32.143353] Call Trace:\n[ 32.143732] ovl_encode_fh+0xd5/0x170\n[ 32.144031] exportfs_encode_inode_fh+0x12f/0x300\n[ 32.144425] show_mark_fhandle+0xbe/0x1f0\n[ 32.145805] inotify_fdinfo+0x226/0x2d0\n[ 32.146442] inotify_show_fdinfo+0x1c5/0x350\n[ 32.147168] seq_show+0x530/0x6f0\n[ 32.147449] seq_read_iter+0x503/0x12a0\n[ 32.148419] seq_read+0x31f/0x410\n[ 32.150714] vfs_read+0x1f0/0x9e0\n[ 32.152297] ksys_read+0x125/0x240\n\nIOW ovl_check_encode_origin derefs inode-\u0026gt;i_sb-\u0026gt;s_root, after it was set\nto NULL in the unmount path.\n\nFix it by protecting calling exportfs_encode_fid() from\nshow_mark_fhandle() with s_umount lock.\n\nThis form of fix was suggested by Amir in [1].\n\n[1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/(CVE-2025-40237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix unlikely race in gdlm_put_lock\n\nIn gdlm_put_lock(), there is a small window of time in which the\nDFL_UNMOUNT flag has been set but the lockspace hasn\u0026apos;t been released,\nyet. In that window, dlm may still call gdlm_ast() and gdlm_bast().\nTo prevent it from dereferencing freed glock objects, only free the\nglock if the lockspace has actually been released.(CVE-2025-40242)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndevlink: rate: Unset parent pointer in devl_rate_nodes_destroy\n\nThe function devl_rate_nodes_destroy is documented to \u0026quot;Unset parent for\nall rate objects\u0026quot;. However, it was only calling the driver-specific\n`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing\nthe parent\u0026apos;s refcount, without actually setting the\n`devlink_rate-\u0026gt;parent` pointer to NULL.\n\nThis leaves a dangling pointer in the `devlink_rate` struct, which cause\nrefcount error in netdevsim[1] and mlx5[2]. In addition, this is\ninconsistent with the behavior of `devlink_nl_rate_parent_node_set`,\nwhere the parent pointer is correctly cleared.\n\nThis patch fixes the issue by explicitly setting `devlink_rate-\u0026gt;parent`\nto NULL after notifying the driver, thus fulfilling the function\u0026apos;s\ndocumented behavior for all rate objects.\n\n[1]\nrepro steps:\necho 1 \u0026gt; /sys/bus/netdevsim/new_device\ndevlink dev eswitch set netdevsim/netdevsim1 mode switchdev\necho 1 \u0026gt; /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs\ndevlink port function rate add netdevsim/netdevsim1/test_node\ndevlink port function rate set netdevsim/netdevsim1/128 parent test_node\necho 1 \u0026gt; /sys/bus/netdevsim/del_device\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n devl_rate_leaf_destroy+0x8d/0x90\n __nsim_dev_port_del+0x6c/0x70 [netdevsim]\n nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]\n nsim_drv_remove+0x2b/0xb0 [netdevsim]\n device_release_driver_internal+0x194/0x1f0\n bus_remove_device+0xc6/0x130\n device_del+0x159/0x3c0\n device_unregister+0x1a/0x60\n del_device_store+0x111/0x170 [netdevsim]\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x55/0x10f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\ndevlink dev eswitch set pci/0000:08:00.0 mode switchdev\ndevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000\ndevlink port function rate add pci/0000:08:00.0/group1\ndevlink port function rate set pci/0000:08:00.0/32768 parent group1\nmodprobe -r mlx5_ib mlx5_fwctl mlx5_core\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n devl_rate_leaf_destroy+0x8d/0x90\n mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]\n mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]\n mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]\n mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]\n notifier_call_chain+0x33/0xa0\n blocking_notifier_call_chain+0x3b/0x50\n mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]\n mlx5_eswitch_disable+0x63/0x90 [mlx5_core]\n mlx5_unload+0x1d/0x170 [mlx5_core]\n mlx5_uninit_one+0xa2/0x130 [mlx5_core]\n remove_one+0x78/0xd0 [mlx5_core]\n pci_device_remove+0x39/0xa0\n device_release_driver_internal+0x194/0x1f0\n unbind_store+0x99/0xa0\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x53/0x1f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-40251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u0026gt;dev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026amp;proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026amp;proc_subdir_lock);\n [time window] | rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n | write_unlock(\u0026amp;proc_subdir_lock);\n read_lock(\u0026amp;proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)(CVE-2025-40271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/secretmem: fix use-after-free race in fault handler\n\nWhen a page fault occurs in a secret memory file created with\n`memfd_secret(2)`, the kernel will allocate a new folio for it, mark the\nunderlying page as not-present in the direct map, and add it to the file\nmapping.\n\nIf two tasks cause a fault in the same page concurrently, both could end\nup allocating a folio and removing the page from the direct map, but only\none would succeed in adding the folio to the file mapping. The task that\nfailed undoes the effects of its attempt by (a) freeing the folio again\nand (b) putting the page back into the direct map. However, by doing\nthese two operations in this order, the page becomes available to the\nallocator again before it is placed back in the direct mapping.\n\nIf another task attempts to allocate the page between (a) and (b), and the\nkernel tries to access it via the direct map, it would result in a\nsupervisor not-present page fault.\n\nFix the ordering to restore the direct map before the folio is freed.(CVE-2025-40272)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE\n\nThis data originates from userspace and is used in buffer offset\ncalculations which could potentially overflow causing an out-of-bounds\naccess.(CVE-2025-40277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()\n\nIn the parse_adv_monitor_pattern() function, the value of\nthe \u0026apos;length\u0026apos; variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251).\nThe size of the \u0026apos;value\u0026apos; array in the mgmt_adv_pattern structure is 31.\nIf the value of \u0026apos;pattern[i].length\u0026apos; is set in the user space\nand exceeds 31, the \u0026apos;patterns[i].value\u0026apos; array can be accessed\nout of bound when copied.\n\nIncreasing the size of the \u0026apos;value\u0026apos; array in\nthe \u0026apos;mgmt_adv_pattern\u0026apos; structure will break the userspace.\nConsidering this, and to avoid OOB access revert the limits for \u0026apos;offset\u0026apos;\nand \u0026apos;length\u0026apos; back to the value of HCI_MAX_AD_LENGTH.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with SVACE.(CVE-2025-40294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: validate skb length for unknown CC opcode\n\nIn hci_cmd_complete_evt(), if the command complete event has an unknown\nopcode, we assume the first byte of the remaining skb-\u0026gt;data contains the\nreturn status. However, parameter data has previously been pulled in\nhci_event_func(), which may leave the skb empty. If so, using skb-\u0026gt;data[0]\nfor the return status uses un-init memory.\n\nThe fix is to check skb-\u0026gt;len before using skb-\u0026gt;data.(CVE-2025-40301)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bcsp: receive data only if registered\n\nCurrently, bcsp_recv() can be called even when the BCSP protocol has not\nbeen registered. This leads to a NULL pointer dereference, as shown in\nthe following stack trace:\n\n KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]\n RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590\n Call Trace:\n \u0026lt;TASK\u0026gt;\n hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627\n tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290\n tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nTo prevent this, ensure that the HCI_UART_REGISTERED flag is set before\nprocessing received data. If the protocol is not registered, return\n-EUNATCH.(CVE-2025-40308)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once\n\nhci_cmd_sync_dequeue_once() does lookup and then cancel\nthe entry under two separate lock sections. Meanwhile,\nhci_cmd_sync_work() can also delete the same entry,\nleading to double list_del() and \u0026quot;UAF\u0026quot;.\n\nFix this by holding cmd_sync_work_lock across both\nlookup and cancel, so that the entry cannot be removed\nconcurrently.(CVE-2025-40318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Don\u0026apos;t leak robust_list pointer on exec race\n\nsys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()\nto check if the calling task is allowed to access another task\u0026apos;s\nrobust_list pointer. This check is racy against a concurrent exec() in the\ntarget process.\n\nDuring exec(), a task may transition from a non-privileged binary to a\nprivileged one (e.g., setuid binary) and its credentials/memory mappings\nmay change. If get_robust_list() performs ptrace_may_access() before\nthis transition, it may erroneously allow access to sensitive information\nafter the target becomes privileged.\n\nA racy access allows an attacker to exploit a window during which\nptrace_may_access() passes before a target process transitions to a\nprivileged state via exec().\n\nFor example, consider a non-privileged task T that is about to execute a\nsetuid-root binary. An attacker task A calls get_robust_list(T) while T\nis still unprivileged. Since ptrace_may_access() checks permissions\nbased on current credentials, it succeeds. However, if T begins exec\nimmediately afterwards, it becomes privileged and may change its memory\nmappings. Because get_robust_list() proceeds to access T-\u0026gt;robust_list\nwithout synchronizing with exec() it may read user-space pointers from a\nnow-privileged process.\n\nThis violates the intended post-exec access restrictions and could\nexpose sensitive memory addresses or be used as a primitive in a larger\nexploit chain. Consequently, the race can lead to unauthorized\ndisclosure of information across privilege boundaries and poses a\npotential security risk.\n\nTake a read lock on signal-\u0026gt;exec_update_lock prior to invoking\nptrace_may_access() and accessing the robust_list/compat_robust_list.\nThis ensures that the target task\u0026apos;s exec state remains stable during the\ncheck, allowing for consistent and synchronized validation of\ncredentials.(CVE-2025-40341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: use lock accessing port_state and rport state\n\nnvme_fc_unregister_remote removes the remote port on a lport object at\nany point in time when there is no active association. This races with\nwith the reconnect logic, because nvme_fc_create_association is not\ntaking a lock to check the port_state and atomically increase the\nactive count on the rport.(CVE-2025-40342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-fc: avoid scheduling association deletion twice\n\nWhen forcefully shutting down a port via the configfs interface,\nnvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and\nthen nvmet_disable_port(). Both functions will eventually schedule all\nremaining associations for deletion.\n\nThe current implementation checks whether an association is about to be\nremoved, but only after the work item has already been scheduled. As a\nresult, it is possible for the first scheduled work item to free all\nresources, and then for the same work item to be scheduled again for\ndeletion.\n\nBecause the association list is an RCU list, it is not possible to take\na lock and remove the list entry directly, so it cannot be looked up\nagain. Instead, a flag (terminating) must be used to determine whether\nthe association is already in the process of being deleted.(CVE-2025-40343)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Fix incorrect error check in topology_parse_cpu_capacity()\n\nFix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()\nwhich causes the code to proceed with NULL clock pointers. The current\nlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both\nvalid pointers and NULL, leading to potential NULL pointer dereference\nin clk_get_rate().\n\nPer include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:\n\u0026quot;The error code within @ptr if it is an error pointer; 0 otherwise.\u0026quot;\n\nThis means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL\npointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)\nwhen cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be\ncalled when of_clk_get() returns NULL.\n\nReplace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid\npointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()\n\nThe syzbot reported issue in hfsplus_delete_cat():\n\n[ 70.682285][ T9333] =====================================================\n[ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220\n[ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220\n[ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0\n[ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310\n[ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810\n[ 70.685447][ T9333] do_rmdir+0x964/0xea0\n[ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0\n[ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0\n[ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.687646][ T9333]\n[ 70.687856][ T9333] Uninit was stored to memory at:\n[ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0\n[ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800\n[ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600\n[ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70\n[ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0\n[ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30\n[ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0\n[ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0\n[ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.692773][ T9333]\n[ 70.692990][ T9333] Uninit was stored to memory at:\n[ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0\n[ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800\n[ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700\n[ 70.694911][ T9333] mount_bdev+0x37b/0x530\n[ 70.695320][ T9333] hfsplus_mount+0x4d/0x60\n[ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0\n[ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0\n[ 70.696588][ T9333] do_new_mount+0x73e/0x1630\n[ 70.697013][ T9333] path_mount+0x6e3/0x1eb0\n[ 70.697425][ T9333] __se_sys_mount+0x733/0x830\n[ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150\n[ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0\n[ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.699730][ T9333]\n[ 70.699946][ T9333] Uninit was created at:\n[ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60\n[ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0\n[ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0\n[ 70.701774][ T9333] allocate_slab+0x30e/0x1390\n[ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0\n[ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20\n[ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0\n[ 70.703598][ T9333] alloc_inode+0x82/0x490\n[ 70.703984][ T9333] iget_locked+0x22e/0x1320\n[ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0\n[ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0\n[ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700\n[ 70.705776][ T9333] mount_bdev+0x37b/0x530\n[ 70.706171][ T9333] hfsplus_mount+0x4d/0x60\n[ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0\n[ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0\n[ 70.707444][ T9333] do_new_mount+0x73e/0x1630\n[ 70.707865][ T9333] path_mount+0x6e3/0x1eb0\n[ 70.708270][ T9333] __se_sys_mount+0x733/0x830\n[ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150\n[ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0\n[ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0\n[ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 70.710611][ T9333]\n[ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17\n[ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 70.712490][ T9333] =====================================================\n[ 70.713085][ T9333] Disabling lock debugging due to kernel taint\n[ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...\n[ 70.714159][ T9333] \n---truncated---(CVE-2025-40351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: stacktrace: Disable KASAN checks for non-current tasks\n\nUnwinding the stack of a task other than current, KASAN would report\n\u0026quot;BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460\u0026quot;\n\nThere is a same issue on x86 and has been resolved by the commit\n84936118bdf3 (\u0026quot;x86/unwind: Disable KASAN checks for non-current tasks\u0026quot;)\nThe solution could be applied to RISC-V too.\n\nThis patch also can solve the issue:\nhttps://seclists.org/oss-sec/2025/q4/23\n\n[(CVE-2025-40358)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: Fix KASAN global-out-of-bounds warning\n\nWhen running \u0026quot;perf mem record\u0026quot; command on CWF, the below KASAN\nglobal-out-of-bounds warning is seen.\n\n ==================================================================\n BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0\n Read of size 4 at addr ffffffffb721d000 by task dtlb/9850\n\n Call Trace:\n\n kasan_report+0xb8/0xf0\n cmt_latency_data+0x176/0x1b0\n setup_arch_pebs_sample_data+0xf49/0x2560\n intel_pmu_drain_arch_pebs+0x577/0xb00\n handle_pmi_common+0x6c4/0xc80\n\nThe issue is caused by below code in __grt_latency_data(). The code\ntries to access x86_hybrid_pmu structure which doesn\u0026apos;t exist on\nnon-hybrid platform like CWF.\n\n WARN_ON_ONCE(hybrid_pmu(event-\u0026gt;pmu)-\u0026gt;pmu_type == hybrid_big)\n\nSo add is_hybrid() check before calling this WARN_ON_ONCE to fix the\nglobal-out-of-bounds access issue.(CVE-2025-40359)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-40361)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Ensure XFD state on signal delivery\n\nSean reported [1] the following splat when running KVM tests:\n\n WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70\n Call Trace:\n \u0026lt;TASK\u0026gt;\n fpu__clear_user_states+0x9c/0x100\n arch_do_signal_or_restart+0x142/0x210\n exit_to_user_mode_loop+0x55/0x100\n do_syscall_64+0x205/0x2c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nChao further identified [2] a reproducible scenario involving signal\ndelivery: a non-AMX task is preempted by an AMX-enabled task which\nmodifies the XFD MSR.\n\nWhen the non-AMX task resumes and reloads XSTATE with init values,\na warning is triggered due to a mismatch between fpstate::xfd and the\nCPU\u0026apos;s current XFD state. fpu__clear_user_states() does not currently\nre-synchronize the XFD state after such preemption.\n\nInvoke xfd_update_state() which detects and corrects the mismatch if\nthere is a dynamic feature.\n\nThis also benefits the sigreturn path, as fpu__restore_sig() may call\nfpu__clear_user_states() when the sigframe is inaccessible.\n\n[ dhansen: minor changelog munging ](CVE-2025-68171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix softlockup in ftrace_module_enable\n\nA soft lockup was observed when loading amdgpu module.\nIf a module has a lot of tracable functions, multiple calls\nto kallsyms_lookup can spend too much time in RCU critical\nsection and with disabled preemption, causing kernel panic.\nThis is the same issue that was fixed in\ncommit d0b24b4e91fc (\u0026quot;ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY\nkernels\u0026quot;) and commit 42ea22e754ba (\u0026quot;ftrace: Add cond_resched() to\nftrace_graph_set_hash()\u0026quot;).\n\nFix it the same way by adding cond_resched() in ftrace_module_enable.(CVE-2025-68173)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\namd/amdkfd: enhance kfd process check in switch partition\n\ncurrent switch partition only check if kfd_processes_table is empty.\nkfd_prcesses_table entry is deleted in kfd_process_notifier_release, but\nkfd_process tear down is in kfd_process_wq_release.\n\nconsider two processes:\n\nProcess A (workqueue) -\u0026gt; kfd_process_wq_release -\u0026gt; Access kfd_node member\nProcess B switch partition -\u0026gt; amdgpu_xcp_pre_partition_switch -\u0026gt; amdgpu_amdkfd_device_fini_sw\n-\u0026gt; kfd_node tear down.\n\nProcess A and B may trigger a race as shown in dmesg log.\n\nThis patch is to resolve the race by adding an atomic kfd_process counter\nkfd_processes_count, it increment as create kfd process, decrement as\nfinish kfd_process_wq_release.\n\nv2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds\nand bug fix. (Philip Yang)\n\n[3966658.307702] divide error: 0000 [#1] SMP NOPTI\n[3966658.350818] i10nm_edac\n[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted\n[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]\n[3966658.362839] nfit\n[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu]\n[3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 \u0026lt;f7\u0026gt; be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00\n[3966658.380967] x86_pkg_temp_thermal\n[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246\n[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000\n[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00\n[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4\n[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000\n[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800\n[3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000\n[3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0\n[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[3966658.391536] PKRU: 55555554\n[3966658.391536] Call Trace:\n[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu]\n[3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu]\n[3966658.399754] intel_powerclamp\n[3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu]\n[3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu]\n[3966658.410516] coretemp\n[3966658.434016] process_one_work+0x1ad/0x380\n[3966658.434021] worker_thread+0x49/0x310\n[3966658.438963] kvm_intel\n[3966658.446041] ? process_one_work+0x380/0x380\n[3966658.446045] kthread+0x118/0x140\n[3966658.446047] ? __kthread_bind_mask+0x60/0x60\n[3966658.446050] ret_from_fork+0x1f/0x30\n[3966658.446053] Modules linked in: kpatch_20765354(OEK)\n[3966658.455310] kvm\n[3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)\n[3966658.473462] idxd_mdev\n[3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo\n---truncated---(CVE-2025-68174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: cadence: Check for the existence of cdns_pcie::ops before using it\n\ncdns_pcie::ops might not be populated by all the Cadence glue drivers. This\nis going to be true for the upcoming Sophgo platform which doesn\u0026apos;t set the\nops.\n\nHence, add a check to prevent NULL pointer dereference.\n\n[mani: reworded subject and description](CVE-2025-68176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()\n\nUse RCU to avoid a pair of atomic operations and a potential\nUAF on dst_dev()-\u0026gt;flags.(CVE-2025-68188)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Add bpf_prog_run_data_pointers()\n\nsyzbot found that cls_bpf_classify() is able to change\ntc_skb_cb(skb)-\u0026gt;drop_reason triggering a warning in sk_skb_reason_drop().\n\nWARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]\nWARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214\n\nstruct tc_skb_cb has been added in commit ec624fe740b4 (\u0026quot;net/sched:\nExtend qdisc control block with tc control block\u0026quot;), which added a wrong\ninteraction with db58ba459202 (\u0026quot;bpf: wire in data and data_end for\ncls_act_bpf\u0026quot;).\n\ndrop_reason was added later.\n\nAdd bpf_prog_run_data_pointers() helper to save/restore the net_sched\nstorage colliding with BPF data_meta/data_end.(CVE-2025-68200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: add seqadj extension for natted connections\n\nSequence adjustment may be required for FTP traffic with PASV/EPSV modes.\ndue to need to re-write packet payload (IP, port) on the ftp control\nconnection. This can require changes to the TCP length and expected\nseq / ack_seq.\n\nThe easiest way to reproduce this issue is with PASV mode.\nExample ruleset:\ntable inet ftp_nat {\n ct helper ftp_helper {\n type \u0026quot;ftp\u0026quot; protocol tcp\n l3proto inet\n }\n\n chain prerouting {\n type filter hook prerouting priority 0; policy accept;\n tcp dport 21 ct state new ct helper set \u0026quot;ftp_helper\u0026quot;\n }\n}\ntable ip nat {\n chain prerouting {\n type nat hook prerouting priority -100; policy accept;\n tcp dport 21 dnat ip prefix to ip daddr map {\n\t\t\t192.168.100.1 : 192.168.13.2/32 }\n }\n\n chain postrouting {\n type nat hook postrouting priority 100 ; policy accept;\n tcp sport 21 snat ip prefix to ip saddr map {\n\t\t\t192.168.13.2 : 192.168.100.1/32 }\n }\n}\n\nNote that the ftp helper gets assigned *after* the dnat setup.\n\nThe inverse (nat after helper assign) is handled by an existing\ncheck in nf_nat_setup_info() and will not show the problem.\n\nTopoloy:\n\n +-------------------+ +----------------------------------+\n | FTP: 192.168.13.2 | \u0026lt;-\u0026gt; | NAT: 192.168.13.3, 192.168.100.1 |\n +-------------------+ +----------------------------------+\n |\n +-----------------------+\n | Client: 192.168.100.2 |\n +-----------------------+\n\nftp nat changes do not work as expected in this case:\nConnected to 192.168.100.1.\n[..]\nftp\u0026gt; epsv\nEPSV/EPRT on IPv4 off.\nftp\u0026gt; ls\n227 Entering passive mode (192,168,100,1,209,129).\n421 Service not available, remote server has closed connection.\n\nKernel logs:\nMissing nfct_seqadj_ext_add() setup call\nWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41\n[..]\n __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat]\n nf_nat_ftp+0x142/0x280 [nf_nat_ftp]\n help+0x4d1/0x880 [nf_conntrack_ftp]\n nf_confirm+0x122/0x2e0 [nf_conntrack]\n nf_hook_slow+0x3c/0xb0\n ..\n\nFix this by adding the required extension when a conntrack helper is assigned\nto a connection that has a nat binding.(CVE-2025-68206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: account for current allocated stack depth in widen_imprecise_scalars()\n\nThe usage pattern for widen_imprecise_scalars() looks as follows:\n\n prev_st = find_prev_entry(env, ...);\n queued_st = push_stack(...);\n widen_imprecise_scalars(env, prev_st, queued_st);\n\nWhere prev_st is an ancestor of the queued_st in the explored states\ntree. This ancestor is not guaranteed to have same allocated stack\ndepth as queued_st. E.g. in the following case:\n\n def main():\n for i in 1..2:\n foo(i) // same callsite, differnt param\n\n def foo(i):\n if i == 1:\n use 128 bytes of stack\n iterator based loop\n\nHere, for a second \u0026apos;foo\u0026apos; call prev_st-\u0026gt;allocated_stack is 128,\nwhile queued_st-\u0026gt;allocated_stack is much smaller.\nwiden_imprecise_scalars() needs to take this into account and avoid\naccessing bpf_verifier_state-\u0026gt;frame[*]-\u0026gt;stack out of bounds.(CVE-2025-68208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot\n\nnvkm_falcon_fw::boot is allocated, but no one frees it. This causes a\nkmemleak warning.\n\nMake sure this data is deallocated.(CVE-2025-68235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Don\u0026apos;t skip unrelated instruction if INT3/INTO is replaced\n\nWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTn\ninstruction, discard the exception and retry the instruction if the code\nstream is changed (e.g. by a different vCPU) between when the CPU\nexecutes the instruction and when KVM decodes the instruction to get the\nnext RIP.\n\nAs effectively predicted by commit 6ef88d6e36c2 (\u0026quot;KVM: SVM: Re-inject\nINT3/INTO instead of retrying the instruction\u0026quot;), failure to verify that\nthe correct INTn instruction was decoded can effectively clobber guest\nstate due to decoding the wrong instruction and thus specifying the\nwrong next RIP.\n\nThe bug most often manifests as \u0026quot;Oops: int3\u0026quot; panics on static branch\nchecks in Linux guests. Enabling or disabling a static branch in Linux\nuses the kernel\u0026apos;s \u0026quot;text poke\u0026quot; code patching mechanism. To modify code\nwhile other CPUs may be executing that code, Linux (temporarily)\nreplaces the first byte of the original instruction with an int3 (opcode\n0xcc), then patches in the new code stream except for the first byte,\nand finally replaces the int3 with the first byte of the new code\nstream. If a CPU hits the int3, i.e. executes the code while it\u0026apos;s being\nmodified, then the guest kernel must look up the RIP to determine how to\nhandle the #BP, e.g. by emulating the new instruction. If the RIP is\nincorrect, then this lookup fails and the guest kernel panics.\n\nThe bug reproduces almost instantly by hacking the guest kernel to\nrepeatedly check a static branch[1] while running a drgn script[2] on\nthe host to constantly swap out the memory containing the guest\u0026apos;s TSS.\n\n[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a\n[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b(CVE-2025-68259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: add i_data_sem protection in ext4_destroy_inline_data_nolock()\n\nFix a race between inline data destruction and block mapping.\n\nThe function ext4_destroy_inline_data_nolock() changes the inode data\nlayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.\nAt the same time, another thread may execute ext4_map_blocks(), which\ntests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()\nor ext4_ind_map_blocks().\n\nWithout i_data_sem protection, ext4_ind_map_blocks() may receive inode\nwith EXT4_INODE_EXTENTS flag and triggering assert.\n\nkernel BUG at fs/ext4/indirect.c:546!\nEXT4-fs (loop2): unmounting filesystem.\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681\n _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822\n ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124\n ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255\n ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000\n generic_perform_write+0x259/0x5d0 mm/filemap.c:3846\n ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285\n ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679\n call_write_iter include/linux/fs.h:2271 [inline]\n do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735\n do_iter_write+0x186/0x710 fs/read_write.c:861\n vfs_iter_write+0x70/0xa0 fs/read_write.c:902\n iter_file_splice_write+0x73b/0xc90 fs/splice.c:685\n do_splice_from fs/splice.c:763 [inline]\n direct_splice_actor+0x10f/0x170 fs/splice.c:950\n splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896\n do_splice_direct+0x1a9/0x280 fs/splice.c:1002\n do_sendfile+0xb13/0x12c0 fs/read_write.c:1255\n __do_sys_sendfile64 fs/read_write.c:1323 [inline]\n __se_sys_sendfile64 fs/read_write.c:1309 [inline]\n __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2025-68261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: refresh inline data size before write operations\n\nThe cached ei-\u0026gt;i_inline_size can become stale between the initial size\ncheck and when ext4_update_inline_data()/ext4_create_inline_data() use\nit. Although ext4_get_max_inline_size() reads the correct value at the\ntime of the check, concurrent xattr operations can modify i_inline_size\nbefore ext4_write_lock_xattr() is acquired.\n\nThis causes ext4_update_inline_data() and ext4_create_inline_data() to\nwork with stale capacity values, leading to a BUG_ON() crash in\next4_write_inline_data():\n\n kernel BUG at fs/ext4/inline.c:1331!\n BUG_ON(pos + len \u0026gt; EXT4_I(inode)-\u0026gt;i_inline_size);\n\nThe race window:\n1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)\n2. Size check passes for 50-byte write\n3. [Another thread adds xattr, i_inline_size changes to 40]\n4. ext4_write_lock_xattr() acquires lock\n5. ext4_update_inline_data() uses stale i_inline_size = 60\n6. Attempts to write 50 bytes but only 40 bytes actually available\n7. BUG_ON() triggers\n\nFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()\nimmediately after acquiring xattr_sem. This ensures ext4_update_inline_data()\nand ext4_create_inline_data() work with current values that are protected\nfrom concurrent modifications.\n\nThis is similar to commit a54c4613dac1 (\u0026quot;ext4: fix race writing to an\ninline_data file while its xattrs are changing\u0026quot;) which fixed i_inline_off\nstaleness. This patch addresses the related i_inline_size staleness issue.(CVE-2025-68264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix admin request_queue lifetime\n\nThe namespaces can access the controller\u0026apos;s admin request_queue, and\nstale references on the namespaces may exist after tearing down the\ncontroller. Ensure the admin request_queue is active by moving the\ncontroller\u0026apos;s \u0026apos;put\u0026apos; to after all controller references have been released\nto ensure no one is can access the request_queue. This fixes a reported\nuse-after-free bug:\n\n BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0\n Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287\n CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15\n Tainted: [E]=UNSIGNED_MODULE\n Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x4f/0x60\n print_report+0xc4/0x620\n ? _raw_spin_lock_irqsave+0x70/0xb0\n ? _raw_read_unlock_irqrestore+0x30/0x30\n ? blk_queue_enter+0x41c/0x4a0\n kasan_report+0xab/0xe0\n ? blk_queue_enter+0x41c/0x4a0\n blk_queue_enter+0x41c/0x4a0\n ? __irq_work_queue_local+0x75/0x1d0\n ? blk_queue_start_drain+0x70/0x70\n ? irq_work_queue+0x18/0x20\n ? vprintk_emit.part.0+0x1cc/0x350\n ? wake_up_klogd_work_func+0x60/0x60\n blk_mq_alloc_request+0x2b7/0x6b0\n ? __blk_mq_alloc_requests+0x1060/0x1060\n ? __switch_to+0x5b7/0x1060\n nvme_submit_user_cmd+0xa9/0x330\n nvme_user_cmd.isra.0+0x240/0x3f0\n ? force_sigsegv+0xe0/0xe0\n ? nvme_user_cmd64+0x400/0x400\n ? vfs_fileattr_set+0x9b0/0x9b0\n ? cgroup_update_frozen_flag+0x24/0x1c0\n ? cgroup_leave_frozen+0x204/0x330\n ? nvme_ioctl+0x7c/0x2c0\n blkdev_ioctl+0x1a8/0x4d0\n ? blkdev_common_ioctl+0x1930/0x1930\n ? fdget+0x54/0x380\n __x64_sys_ioctl+0x129/0x190\n do_syscall_64+0x5b/0x160\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f765f703b0b\n Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48\n RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b\n RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003\n RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000\n R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003\n R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60\n \u0026lt;/TASK\u0026gt;(CVE-2025-68265)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix crash in process_v2_sparse_read() for encrypted directories\n\nThe crash in process_v2_sparse_read() for fscrypt-encrypted directories\nhas been reported. Issue takes place for Ceph msgr2 protocol in secure\nmode. It can be reproduced by the steps:\n\nsudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure\n\n(1) mkdir /mnt/cephfs/fscrypt-test-3\n(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3\n(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3\n(4) fscrypt lock /mnt/cephfs/fscrypt-test-3\n(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3\n(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar\n(7) Issue has been triggered\n\n[ 408.072247] ------------[ cut here ]------------\n[ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865\nceph_con_v2_try_read+0x4b39/0x72f0\n[ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common\nintel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery\npmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass\npolyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse\nserio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg\npata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore\n[ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+\n[ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.17.0-5.fc42 04/01/2014\n[ 408.072310] Workqueue: ceph-msgr ceph_con_workfn\n[ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0\n[ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8\n8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff \u0026lt;0f\u0026gt; 0b e9 06\nfe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85\n[ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246\n[ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38\n[ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8\n[ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8\n[ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000\n[ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000)\nknlGS:0000000000000000\n[ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0\n[ 408.072336] PKRU: 55555554\n[ 408.072337] Call Trace:\n[ 408.072338] \u0026lt;TASK\u0026gt;\n[ 408.072340] ? sched_clock_noinstr+0x9/0x10\n[ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10\n[ 408.072347] ? _raw_spin_unlock+0xe/0x40\n[ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830\n[ 408.072353] ? __kasan_check_write+0x14/0x30\n[ 408.072357] ? mutex_lock+0x84/0xe0\n[ 408.072359] ? __pfx_mutex_lock+0x10/0x10\n[ 408.072361] ceph_con_workfn+0x27e/0x10e0\n[ 408.072364] ? metric_delayed_work+0x311/0x2c50\n[ 408.072367] process_one_work+0x611/0xe20\n[ 408.072371] ? __kasan_check_write+0x14/0x30\n[ 408.072373] worker_thread+0x7e3/0x1580\n[ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 408.072378] ? __pfx_worker_thread+0x10/0x10\n[ 408.072381] kthread+0x381/0x7a0\n[ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 408.072385] ? __pfx_kthread+0x10/0x10\n[ 408.072387] ? __kasan_check_write+0x14/0x30\n[ 408.072389] ? recalc_sigpending+0x160/0x220\n[ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50\n[ 408.072394] ? calculate_sigpending+0x78/0xb0\n[ 408.072395] ? __pfx_kthread+0x10/0x10\n[ 408.072397] ret_from_fork+0x2b6/0x380\n[ 408.072400] ? __pfx_kthread+0x10/0x10\n[ 408.072402] ret_from_fork_asm+0x1a/0x30\n[ 408.072406] \u0026lt;/TASK\u0026gt;\n[ 408.072407] ---[ end trace 0000000000000000 ]---\n[ 408.072418] Oops: general protection fault, probably for non-canonical\naddress 0xdffffc00000000\n---truncated---(CVE-2025-68297)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atlantic: fix fragment overflow handling in RX path\n\nThe atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)\nfragments when handling large multi-descriptor packets. This causes an\nout-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.\n\nThe issue occurs because the driver doesn\u0026apos;t check the total number of\nfragments before calling skb_add_rx_frag(). When a packet requires more\nthan MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.\n\nFix by assuming there will be an extra frag if buff-\u0026gt;len \u0026gt; AQ_CFG_RX_HDR_SIZE,\nthen all fragments are accounted for. And reusing the existing check to\nprevent the overflow earlier in the code path.\n\nThis crash occurred in production with an Aquantia AQC113 10G NIC.\n\nStack trace from production environment:\n```\nRIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0\nCode: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89\nca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90\nc8 00 00 00 \u0026lt;48\u0026gt; 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48\n89 fa 83\nRSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287\nRAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:\nfffffffe0a0c8000\nRDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:\n0000000000037a40\nRBP: 0000000000000024 R08: 0000000000000000 R09:\n0000000000000021\nR10: 0000000000000848 R11: 0000000000000000 R12:\nffffa9bec02a8e24\nR13: ffff925ad8615570 R14: 0000000000000000 R15:\nffff925b22e80a00\nFS: 0000000000000000(0000)\nGS:ffff925e47880000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:\n0000000000f72ef0\nPKRU: 55555554\nCall Trace:\n\u0026lt;IRQ\u0026gt;\naq_ring_rx_clean+0x175/0xe60 [atlantic]\n? aq_ring_rx_clean+0x14d/0xe60 [atlantic]\n? aq_ring_tx_clean+0xdf/0x190 [atlantic]\n? kmem_cache_free+0x348/0x450\n? aq_vec_poll+0x81/0x1d0 [atlantic]\n? __napi_poll+0x28/0x1c0\n? net_rx_action+0x337/0x420\n```\n\nChanges in v4:\n- Add Fixes: tag to satisfy patch validation requirements.\n\nChanges in v3:\n- Fix by assuming there will be an extra frag if buff-\u0026gt;len \u0026gt; AQ_CFG_RX_HDR_SIZE,\n then all fragments are accounted for.(CVE-2025-68301)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI/AER: Fix NULL pointer access by aer_info\n\nThe kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info-\u0026gt;xxx\nwill result in kernel panic. Fix it.(CVE-2025-68309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer\n\nWhen a UAS device is unplugged during data transfer, there is\na probability of a system panic occurring. The root cause is\nan access to an invalid memory address during URB callback handling.\nSpecifically, this happens when the dma_direct_unmap_sg() function\nis called within the usb_hcd_unmap_urb_for_dma() interface, but the\nsg-\u0026gt;dma_address field is 0 and the sg data structure has already been\nfreed.\n\nThe SCSI driver sends transfer commands by invoking uas_queuecommand_lck()\nin uas.c, using the uas_submit_urbs() function to submit requests to USB.\nWithin the uas_submit_urbs() implementation, three URBs (sense_urb,\ndata_urb, and cmd_urb) are sequentially submitted. Device removal may\noccur at any point during uas_submit_urbs execution, which may result\nin URB submission failure. However, some URBs might have been successfully\nsubmitted before the failure, and uas_submit_urbs will return the -ENODEV\nerror code in this case. The current error handling directly calls\nscsi_done(). In the SCSI driver, this eventually triggers scsi_complete()\nto invoke scsi_end_request() for releasing the sgtable. The successfully\nsubmitted URBs, when being unlinked to giveback, call\nusb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg\nunmapping operations since the sg data structure has already been freed.\n\nThis patch modifies the error condition check in the uas_submit_urbs()\nfunction. When a UAS device is removed but one or more URBs have already\nbeen successfully submitted to USB, it avoids immediately invoking\nscsi_done() and save the cmnd to devinfo-\u0026gt;cmnd array. If the successfully\nsubmitted URBs is completed before devinfo-\u0026gt;resetting being set, then\nthe scsi_done() function will be called within uas_try_complete() after\nall pending URB operations are finalized. Otherwise, the scsi_done()\nfunction will be called within uas_zap_pending(), which is executed after\nusb_kill_anchored_urbs().\n\nThe error handling only takes effect when uas_queuecommand_lck() calls\nuas_submit_urbs() and returns the error value -ENODEV . In this case,\nthe device is disconnected, and the flow proceeds to uas_disconnect(),\nwhere uas_zap_pending() is invoked to call uas_try_complete().(CVE-2025-68331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted\n\nThere\u0026apos;s issue when file system corrupted:\n------------[ cut here ]------------\nkernel BUG at fs/jbd2/transaction.c:1289!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next\nRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0\nRSP: 0018:ffff888117aafa30 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534\nRDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010\nRBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028\nR10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __ext4_journal_get_create_access+0x42/0x170\n ext4_getblk+0x319/0x6f0\n ext4_bread+0x11/0x100\n ext4_append+0x1e6/0x4a0\n ext4_init_new_dir+0x145/0x1d0\n ext4_mkdir+0x326/0x920\n vfs_mkdir+0x45c/0x740\n do_mkdirat+0x234/0x2f0\n __x64_sys_mkdir+0xd6/0x120\n do_syscall_64+0x5f/0xfa0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe above issue occurs with us in errors=continue mode when accompanied by\nstorage failures. There have been many inconsistencies in the file system\ndata.\nIn the case of file system data inconsistency, for example, if the block\nbitmap of a referenced block is not set, it can lead to the situation where\na block being committed is allocated and used again. As a result, the\nfollowing condition will not be satisfied then trigger BUG_ON. Of course,\nit is entirely possible to construct a problematic image that can trigger\nthis BUG_ON through specific operations. In fact, I have constructed such\nan image and easily reproduced this issue.\nTherefore, J_ASSERT() holds true only under ideal conditions, but it may\nnot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()\ndirectly in abnormal situations would cause the system to crash, which is\nclearly not what we want. So here we directly trigger a JBD abort instead\nof immediately invoking BUG_ON.(CVE-2025-68337)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid\n\nFixes a crash when layout is null during this call stack:\n\nwrite_inode\n -\u0026gt; nfs4_write_inode\n -\u0026gt; pnfs_layoutcommit_inode\n\npnfs_set_layoutcommit relies on the lseg refcount to keep the layout\naround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt\nto reference a null layout.(CVE-2025-68349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Protect regulator_supply_alias_list with regulator_list_mutex\n\nregulator_supply_alias_list was accessed without any locking in\nregulator_supply_alias(), regulator_register_supply_alias(), and\nregulator_unregister_supply_alias(). Concurrent registration,\nunregistration and lookups can race, leading to:\n\n1 use-after-free if an alias entry is removed while being read,\n2 duplicate entries when two threads register the same alias,\n3 inconsistent alias mappings observed by consumers.\n\nProtect all traversals, insertions and deletions on\nregulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Prevent recursive memory reclaim\n\nFunction new_inode() returns a new inode with inode-\u0026gt;i_mapping-\u0026gt;gfp_mask\nset to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so\nallocations in that address space can recurse into filesystem memory\nreclaim. We don\u0026apos;t want that to happen because it can consume a\nsignificant amount of stack memory.\n\nWorse than that is that it can also deadlock: for example, in several\nplaces, gfs2_unstuff_dinode() is called inside filesystem transactions.\nThis calls filemap_grab_folio(), which can allocate a new folio, which\ncan trigger memory reclaim. If memory reclaim recurses into the\nfilesystem and starts another transaction, a deadlock will ensue.\n\nTo fix these kinds of problems, prevent memory reclaim from recursing\ninto filesystem code by making sure that the gfp_mask of inode address\nspaces doesn\u0026apos;t include __GFP_FS.\n\nThe \u0026quot;meta\u0026quot; and resource group address spaces were already using GFP_NOFS\nas their gfp_mask (which doesn\u0026apos;t include __GFP_FS). The default value\nof GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To\navoid being overly limiting, use the default value and only knock off\nthe __GFP_FS flag. I\u0026apos;m not sure if this will actually make a\ndifference, but it also shouldn\u0026apos;t hurt.\n\nThis patch is loosely based on commit ad22c7a043c2 (\u0026quot;xfs: prevent stack\noverflows from page cache allocation\u0026quot;).\n\nFixes xfstest generic/273.(CVE-2025-68356)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()\n\nThe rtl8187_rx_cb() calculates the rx descriptor header address\nby subtracting its size from the skb tail pointer.\nHowever, it does not validate if the received packet\n(skb-\u0026gt;len from urb-\u0026gt;actual_length) is large enough to contain this\nheader.\n\nIf a truncated packet is received, this will lead to a buffer\nunderflow, reading memory before the start of the skb data area,\nand causing a kernel panic.\n\nAdd length checks for both rtl8187 and rtl8187b descriptor headers\nbefore attempting to access them, dropping the packet cleanly if the\ncheck fails.(CVE-2025-68362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check skb-\u0026gt;transport_header is set in bpf_skb_check_mtu\n\nThe bpf_skb_check_mtu helper needs to use skb-\u0026gt;transport_header when\nthe BPF_MTU_CHK_SEGS flag is used:\n\n\tbpf_skb_check_mtu(skb, ifindex, \u0026amp;mtu_len, 0, BPF_MTU_CHK_SEGS)\n\nThe transport_header is not always set. There is a WARN_ON_ONCE\nreport when CONFIG_DEBUG_NET is enabled + skb-\u0026gt;gso_size is set +\nbpf_prog_test_run is used:\n\nWARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071\n skb_gso_validate_network_len\n bpf_skb_check_mtu\n bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch\n bpf_test_run\n bpf_prog_test_run_skb\n\nFor a normal ingress skb (not test_run), skb_reset_transport_header\nis performed but there is plan to avoid setting it as described in\ncommit 2170a1f09148 (\u0026quot;net: no longer reset transport_header in __netif_receive_skb_core()\u0026quot;).\n\nThis patch fixes the bpf helper by checking\nskb_transport_header_was_set(). The check is done just before\nskb-\u0026gt;transport_header is used, to avoid breaking the existing bpf prog.\nThe WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.(CVE-2025-68363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: ETR: Fix ETR buffer use-after-free issue\n\nWhen ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed\nand enabled again, currently sysfs_buf will point to the newly\nallocated memory(buf_new) and free the old memory(buf_old). But the\netr_buf that is being used by the ETR remains pointed to buf_old, not\nupdated to buf_new. In this case, it will result in a memory\nuse-after-free issue.\n\nFix this by checking ETR\u0026apos;s mode before updating and releasing buf_old,\nif the mode is CS_MODE_SYSFS, then skip updating and releasing it.(CVE-2025-68376)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix stackmap overflow check in __bpf_get_stackid()\n\nSyzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()\nwhen copying stack trace data. The issue occurs when the perf trace\n contains more stack entries than the stack map bucket can hold,\n leading to an out-of-bounds write in the bucket\u0026apos;s data array.(CVE-2025-68378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id\n\nUse check_add_overflow() to guard against potential integer overflows\nwhen adding the binary blob lengths and the size of an asymmetric_key_id\nstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a\npossible buffer overflow when copying data from potentially malicious\nX.509 certificate fields that can be arbitrarily large, such as ASN.1\nINTEGER serial numbers, issuer names, etc.(CVE-2025-68724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Do not let BPF test infra emit invalid GSO types to stack\n\nYinhao et al. reported that their fuzzer tool was able to trigger a\nskb_warn_bad_offload() from netif_skb_features() -\u0026gt; gso_features_check().\nWhen a BPF program - triggered via BPF test infra - pushes the packet\nto the loopback device via bpf_clone_redirect() then mentioned offload\nwarning can be seen. GSO-related features are then rightfully disabled.\n\nWe get into this situation due to convert___skb_to_skb() setting\ngso_segs and gso_size but not gso_type. Technically, it makes sense\nthat this warning triggers since the GSO properties are malformed due\nto the gso_type. Potentially, the gso_type could be marked non-trustworthy\nthrough setting it at least to SKB_GSO_DODGY without any other specific\nassumptions, but that also feels wrong given we should not go further\ninto the GSO engine in the first place.\n\nThe checks were added in 121d57af308d (\u0026quot;gso: validate gso_type in GSO\nhandlers\u0026quot;) because there were malicious (syzbot) senders that combine\na protocol with a non-matching gso_type. If we would want to drop such\npackets, gso_features_check() currently only returns feature flags via\nnetif_skb_features(), so one location for potentially dropping such skbs\ncould be validate_xmit_unreadable_skb(), but then otoh it would be\nan additional check in the fast-path for a very corner case. Given\nbpf_clone_redirect() is the only place where BPF test infra could emit\nsuch packets, lets reject them right there.(CVE-2025-68725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()\n\nIn hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when\nsetup_instance() fails with an error code. Fix that by freeing the urb\nbefore freeing the hw structure. Also change the error paths to use the\ngoto ladder style.\n\nCompile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix improper freeing of purex item\n\nIn qla2xxx_process_purls_iocb(), an item is allocated via\nqla27xx_copy_multiple_pkt(), which internally calls\nqla24xx_alloc_purex_item().\n\nThe qla24xx_alloc_purex_item() function may return a pre-allocated item\nfrom a per-adapter pool for small allocations, instead of dynamically\nallocating memory with kzalloc().\n\nAn error handling path in qla2xxx_process_purls_iocb() incorrectly uses\nkfree() to release the item. If the item was from the pre-allocated\npool, calling kfree() on it is a bug that can lead to memory corruption.\n\nFix this by using the correct deallocation function,\nqla24xx_free_purex_item(), which properly handles both dynamically\nallocated and pre-allocated items.(CVE-2025-68741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Free special fields when update [lru_,]percpu_hash maps\n\nAs [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing\ncalls to \u0026apos;bpf_obj_free_fields()\u0026apos; in \u0026apos;pcpu_copy_value()\u0026apos; could cause the\nmemory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the\nmap gets freed.\n\nFix this by calling \u0026apos;bpf_obj_free_fields()\u0026apos; after\n\u0026apos;copy_map_value[,_long]()\u0026apos; in \u0026apos;pcpu_copy_value()\u0026apos;.(CVE-2025-68744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Clear cmds after chip reset\n\nCommit aefed3e5548f (\u0026quot;scsi: qla2xxx: target: Fix offline port handling\nand host reset handling\u0026quot;) caused two problems:\n\n1. Commands sent to FW, after chip reset got stuck and never freed as FW\n is not going to respond to them anymore.\n\n2. BUG_ON(cmd-\u0026gt;sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a\n (\u0026quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands\u0026quot;)\n attempted to fix this, but introduced another bug under different\n circumstances when two different CPUs were racing to call\n qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in\n dma_unmap_sg_attrs().\n\nSo revert \u0026quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands\u0026quot; and\npartially revert \u0026quot;scsi: qla2xxx: target: Fix offline port handling and\nhost reset handling\u0026quot; at __qla2x00_abort_all_cmds.(CVE-2025-68745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: Use RCU in blk_mq_[un]quiesce_tagset() instead of set-\u0026gt;tag_list_lock\n\nblk_mq_{add,del}_queue_tag_set() functions add and remove queues from\ntagset, the functions make sure that tagset and queues are marked as\nshared when two or more queues are attached to the same tagset.\nInitially a tagset starts as unshared and when the number of added\nqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared along\nwith all the queues attached to it. When the number of attached queues\ndrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and\nthe remaining queues as unshared.\n\nBoth functions need to freeze current queues in tagset before setting on\nunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions\nhold set-\u0026gt;tag_list_lock mutex, which makes sense as we do not want\nqueues to be added or deleted in the process. This used to work fine\nuntil commit 98d81f0df70c (\u0026quot;nvme: use blk_mq_[un]quiesce_tagset\u0026quot;)\nmade the nvme driver quiesce tagset instead of quiscing individual\nqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues in\nset-\u0026gt;tag_list while holding set-\u0026gt;tag_list_lock also.\n\nThis results in deadlock between two threads with these stacktraces:\n\n __schedule+0x47c/0xbb0\n ? timerqueue_add+0x66/0xb0\n schedule+0x1c/0xa0\n schedule_preempt_disabled+0xa/0x10\n __mutex_lock.constprop.0+0x271/0x600\n blk_mq_quiesce_tagset+0x25/0xc0\n nvme_dev_disable+0x9c/0x250\n nvme_timeout+0x1fc/0x520\n blk_mq_handle_expired+0x5c/0x90\n bt_iter+0x7e/0x90\n blk_mq_queue_tag_busy_iter+0x27e/0x550\n ? __blk_mq_complete_request_remote+0x10/0x10\n ? __blk_mq_complete_request_remote+0x10/0x10\n ? __call_rcu_common.constprop.0+0x1c0/0x210\n blk_mq_timeout_work+0x12d/0x170\n process_one_work+0x12e/0x2d0\n worker_thread+0x288/0x3a0\n ? rescuer_thread+0x480/0x480\n kthread+0xb8/0xe0\n ? kthread_park+0x80/0x80\n ret_from_fork+0x2d/0x50\n ? kthread_park+0x80/0x80\n ret_from_fork_asm+0x11/0x20\n\n __schedule+0x47c/0xbb0\n ? xas_find+0x161/0x1a0\n schedule+0x1c/0xa0\n blk_mq_freeze_queue_wait+0x3d/0x70\n ? destroy_sched_domains_rcu+0x30/0x30\n blk_mq_update_tag_set_shared+0x44/0x80\n blk_mq_exit_queue+0x141/0x150\n del_gendisk+0x25a/0x2d0\n nvme_ns_remove+0xc9/0x170\n nvme_remove_namespaces+0xc7/0x100\n nvme_remove+0x62/0x150\n pci_device_remove+0x23/0x60\n device_release_driver_internal+0x159/0x200\n unbind_store+0x99/0xa0\n kernfs_fop_write_iter+0x112/0x1e0\n vfs_write+0x2b1/0x3d0\n ksys_write+0x4e/0xb0\n do_syscall_64+0x5b/0x160\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe top stacktrace is showing nvme_timeout() called to handle nvme\ncommand timeout. timeout handler is trying to disable the controller and\nas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not\nto call queue callback handlers. The thread is stuck waiting for\nset-\u0026gt;tag_list_lock as it tries to walk the queues in set-\u0026gt;tag_list.\n\nThe lock is held by the second thread in the bottom stack which is\nwaiting for one of queues to be frozen. The queue usage counter will\ndrop to zero after nvme_timeout() finishes, and this will not happen\nbecause the thread will wait for this mutex forever.\n\nGiven that [un]quiescing queue is an operation that does not need to\nsleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking\nset-\u0026gt;tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU\nsafe list operations. Also, delete INIT_LIST_HEAD(\u0026amp;q-\u0026gt;tag_set_list)\nin blk_mq_del_queue_tag_set() because we can not re-initialize it while\nthe list is being traversed under RCU. The deleted queue will not be\nadded/deleted to/from a tagset and it will be freed in blk_free_queue()\nafter the end of RCU grace period.(CVE-2025-68756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: only set free_cpus for online runqueues\n\nCommit 16b269436b72 (\u0026quot;sched/deadline: Modify cpudl::free_cpus\nto reflect rd-\u0026gt;online\u0026quot;) introduced the cpudl_set/clear_freecpu\nfunctions to allow the cpu_dl::free_cpus mask to be manipulated\nby the deadline scheduler class rq_on/offline callbacks so the\nmask would also reflect this state.\n\nCommit 9659e1eeee28 (\u0026quot;sched/deadline: Remove cpu_active_mask\nfrom cpudl_find()\u0026quot;) removed the check of the cpu_active_mask to\nsave some processing on the premise that the cpudl::free_cpus\nmask already reflected the runqueue online state.\n\nUnfortunately, there are cases where it is possible for the\ncpudl_clear function to set the free_cpus bit for a CPU when the\ndeadline runqueue is offline. When this occurs while a CPU is\nconnected to the default root domain the flag may retain the bad\nstate after the CPU has been unplugged. Later, a different CPU\nthat is transitioning through the default root domain may push a\ndeadline task to the powered down CPU when cpudl_find sees its\nfree_cpus bit is set. If this happens the task will not have the\nopportunity to run.\n\nOne example is outlined here:\nhttps://lore.kernel.org/lkml/(CVE-2025-68780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Reset t_task_cdb pointer in error case\n\nIf allocation of cmd-\u0026gt;t_task_cdb fails, it remains NULL but is later\ndereferenced in the \u0026apos;err\u0026apos; path.\n\nIn case of error, reset NULL t_task_cdb value to point at the default\nfixed-size buffer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niomap: adjust read range correctly for non-block-aligned positions\n\niomap_adjust_read_range() assumes that the position and length passed in\nare block-aligned. This is not always the case however, as shown in the\nsyzbot generated case for erofs. This causes too many bytes to be\nskipped for uptodate blocks, which results in returning the incorrect\nposition and length to read in. If all the blocks are uptodate, this\nunderflows length and returns a position beyond the folio.\n\nFix the calculation to also take into account the block offset when\ncalculating how many bytes can be skipped for uptodate blocks.(CVE-2025-68794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: NFSv4 file creation neglects setting ACL\n\nAn NFSv4 client that sets an ACL with a named principal during file\ncreation retrieves the ACL afterwards, and finds that it is only a\ndefault ACL (based on the mode bits) and not the ACL that was\nrequested during file creation. This violates RFC 8881 section\n6.4.1.3: \u0026quot;the ACL attribute is set as given\u0026quot;.\n\nThe issue occurs in nfsd_create_setattr(), which calls\nnfsd_attrs_valid() to determine whether to call nfsd_setattr().\nHowever, nfsd_attrs_valid() checks only for iattr changes and\nsecurity labels, but not POSIX ACLs. When only an ACL is present,\nthe function returns false, nfsd_setattr() is skipped, and the\nPOSIX ACL is never applied to the inode.\n\nSubsequently, when the client retrieves the ACL, the server finds\nno POSIX ACL on the inode and returns one generated from the file\u0026apos;s\nmode bits rather than returning the originally-specified ACL.(CVE-2025-68803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix filename leak in __io_openat_prep()\n\n __io_openat_prep() allocates a struct filename using getname(). However,\nfor the condition of the file being installed in the fixed file table as\nwell as having O_CLOEXEC flag set, the function returns early. At that\npoint, the request doesn\u0026apos;t have REQ_F_NEED_CLEANUP flag set. Due to this,\nthe memory for the newly allocated struct filename is not cleaned up,\ncausing a memory leak.\n\nFix this by setting the REQ_F_NEED_CLEANUP for the request just after the\nsuccessful getname() call, so that when the request is torn down, the\nfilename will be cleaned up, along with other resources needing cleanup.(CVE-2025-68814)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: fw_tracer, Validate format string parameters\n\nAdd validation for format string parameters in the firmware tracer to\nprevent potential security vulnerabilities and crashes from malformed\nformat strings received from firmware.\n\nThe firmware tracer receives format strings from the device firmware and\nuses them to format trace messages. Without proper validation, bad\nfirmware could provide format strings with invalid format specifiers\n(e.g., %s, %p, %n) that could lead to crashes, or other undefined\nbehavior.\n\nAdd mlx5_tracer_validate_params() to validate that all format specifiers\nin trace strings are limited to safe integer/hex formats (%x, %d, %i,\n%u, %llx, %lx, etc.). Reject strings containing other format types that\ncould be used to access arbitrary memory or cause crashes.\nInvalid format strings are added to the trace output for visibility with\n\u0026quot;BAD_FORMAT: \u0026quot; prefix.(CVE-2025-68816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \u0026quot;scsi: qla2xxx: Perform lockless command completion in abort path\u0026quot;\n\nThis reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.\n\nThe commit being reverted added code to __qla2x00_abort_all_cmds() to\ncall sp-\u0026gt;done() without holding a spinlock. But unlike the older code\nbelow it, this new code failed to check sp-\u0026gt;cmd_type and just assumed\nTYPE_SRB, which results in a jump to an invalid pointer in target-mode\nwith TYPE_TGT_CMD:\n\nqla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success\n 0000000009f7a79b\nqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h\n mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.\nqla2xxx [0000:65:00.0]-d01e:8: -\u0026gt; fwdump no buffer\nqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event\n 0x8002 occurred\nqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -\n ha=0000000058183fda.\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPF: supervisor instruction fetch in kernel mode\nPF: error_code(0x0010) - not-present page\nPGD 0 P4D 0\nOops: 0010 [#1] SMP\nCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1\nHardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206\nRAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000\nRDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0\nRBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045\nR10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40\nR13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400\nFS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x4d/0x8b\n ? page_fault_oops+0x91/0x180\n ? trace_buffer_unlock_commit_regs+0x38/0x1a0\n ? exc_page_fault+0x391/0x5e0\n ? asm_exc_page_fault+0x22/0x30\n __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]\n qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]\n qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]\n qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]\n qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]\n kthread+0xa8/0xd0\n \u0026lt;/TASK\u0026gt;\n\nThen commit 4475afa2646d (\u0026quot;scsi: qla2xxx: Complete command early within\nlock\u0026quot;) added the spinlock back, because not having the lock caused a\nrace and a crash. But qla2x00_abort_srb() in the switch below already\nchecks for qla2x00_chip_is_down() and handles it the same way, so the\ncode above the switch is now redundant and still buggy in target-mode.\nRemove it.(CVE-2025-68818)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nshmem: fix recovery on rename failures\n\nmaple_tree insertions can fail if we are seriously short on memory;\nsimple_offset_rename() does not recover well if it runs into that.\nThe same goes for simple_offset_rename_exchange().\n\nMoreover, shmem_whiteout() expects that if it succeeds, the caller will\nprogress to d_move(), i.e. that shmem_rename2() won\u0026apos;t fail past the\nsuccessful call of shmem_whiteout().\n\nNot hard to fix, fortunately - mtree_store() can\u0026apos;t fail if the index we\nare trying to store into is already present in the tree as a singleton.\n\nFor simple_offset_rename_exchange() that\u0026apos;s enough - we just need to be\ncareful about the order of operations.\n\nFor simple_offset_rename() solution is to preinsert the target into the\ntree for new_dir; the rest can be done without any potentially failing\noperations.\n\nThat preinsertion has to be done in shmem_rename2() rather than in\nsimple_offset_rename() itself - otherwise we\u0026apos;d need to deal with the\npossibility of failure after successful shmem_whiteout().(CVE-2025-71072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest\u0026apos;s APIC timer in periodic\nmode, set the expiration to \u0026quot;now\u0026quot; if the target expiration is in the past\n(similar to what is done in update_target_expiration()). Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over. In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active. As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past. As a result, the delta\nmay be calculated as a negative value. When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming. I.e. the large\nvalue will exceed the VMX Preemption Timer\u0026apos;s maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM\u0026apos;s request for an expiration in the past and\nimmediately re-invokes KVM\u0026apos;s callback after reprogramming. And because\nthe interrupt handler runs with IRQs disabled, restarting KVM\u0026apos;s hrtimer\nover and over until the target expiration is advanced to \u0026quot;now\u0026quot; can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n ...\n RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n ...\n RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n PKRU: 55555554\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n apic_timer_fn+0x31/0x50 [kvm]\n __hrtimer_run_queues+0x100/0x280\n hrtimer_interrupt+0x100/0x210\n ? ttwu_do_wakeup+0x19/0x160\n smp_apic_timer_interrupt+0x6a/0x130\n apic_timer_interrupt+0xf/0x20\n \u0026lt;/IRQ\u0026gt;\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\u0026quot;KVM: VMX: Move preemption timer \u0026lt;=\u0026gt; hrtimer dance to common x86\u0026quot;), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way. Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---(CVE-2025-71104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: make decode_pool() more resilient against corrupted osdmaps\n\nIf the osdmap is (maliciously) corrupted such that the encoded length\nof ceph_pg_pool envelope is less than what is expected for a particular\nencoding version, out-of-bounds reads may ensue because the only bounds\ncheck that is there is based on that length value.\n\nThis patch adds explicit bounds checks for each field that is decoded\nor skipped.(CVE-2025-71116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: seqiv - Do not use req-\u0026gt;iv after crypto_aead_encrypt\n\nAs soon as crypto_aead_encrypt is called, the underlying request\nmay be freed by an asynchronous completion. Thus dereferencing\nreq-\u0026gt;iv after it returns is invalid.\n\nInstead of checking req-\u0026gt;iv against info, create a new variable\nunaligned_info and use it for that purpose instead.(CVE-2025-71131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Fix a memory leak in tpm2_load_cmd\n\n\u0026apos;tpm2_load_cmd\u0026apos; allocates a tempoary blob indirectly via \u0026apos;tpm2_key_decode\u0026apos;\nbut it is not freed in the failure paths. Address this by wrapping the blob\ninto with a cleanup helper.(CVE-2025-71147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/poll: correctly handle io_poll_add() return value on update\n\nWhen the core of io_uring was updated to handle completions\nconsistently and with fixed return codes, the POLL_REMOVE opcode\nwith updates got slightly broken. If a POLL_ADD is pending and\nthen POLL_REMOVE is used to update the events of that request, if that\nupdate causes the POLL_ADD to now trigger, then that completion is lost\nand a CQE is never posted.\n\nAdditionally, ensure that if an update does cause an existing POLL_ADD\nto complete, that the completion value isn\u0026apos;t always overwritten with\n-ECANCELED. For that case, whatever io_poll_add() set the value to\nshould just be retained.(CVE-2025-71149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix refcount leak when invalid session is found on session lookup\n\nWhen a session is found but its state is not SMB2_SESSION_VALID, It\nindicates that no valid session was found, but it is missing to decrement\nthe reference count acquired by the session lookup, which results in\na reference count leak. This patch fixes the issue by explicitly calling\nksmbd_user_session_put to release the reference to the session.(CVE-2025-71150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Don\u0026apos;t store mlx5e_priv in mlx5e_dev devlink priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails, mlx5e_priv in mlx5e_dev devlink private is used to\nreference the netdev and mdev associated with that struct. Instead,\nstore netdev directly into mlx5e_dev and get mdev from the containing\nmlx5_adev aux device structure.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==\u0026gt; oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000520\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_remove+0x68/0x130\nRSP: 0018:ffffc900034838f0 EFLAGS: 00010246\nRAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\nRBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10\nR10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0\nR13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400\nFS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-22996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\u0026quot;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\u0026quot;)\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command\u0026apos;s data structures (cmd-\u0026gt;req.sg and cmd-\u0026gt;iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT \u2192 both pointers NULL\n2. H2C_DATA PDU for READ command \u2192 cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n3. H2C_DATA PDU for uninitialized command slot \u2192 both pointers NULL\n\nThe fix validates both cmd-\u0026gt;req.sg and cmd-\u0026gt;iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n- WRITE commands: both allocated(CVE-2026-22998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash on profile change rollback failure\n\nmlx5e_netdev_change_profile can fail to attach a new profile and can\nfail to rollback to old profile, in such case, we could end up with a\ndangling netdev with a fully reset netdev_priv. A retry to change\nprofile, e.g. another attempt to call mlx5e_netdev_change_profile via\nswitchdev mode change, will crash trying to access the now NULL\npriv-\u0026gt;mdev.\n\nThis fix allows mlx5e_netdev_change_profile() to handle previous\nfailures and an empty priv, by not assuming priv is valid.\n\nPass netdev and mdev to all flows requiring\nmlx5e_netdev_change_profile() and avoid passing priv.\nIn mlx5e_netdev_change_profile() check if current priv is valid, and if\nnot, just attach the new profile without trying to access the old one.\n\nThis fixes the following oops, when enabling switchdev mode for the 2nd\ntime after first time failure:\n\n ## Enabling switchdev mode first time:\n\nmlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n ^^^^^^^^\nmlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\n\n ## retry: Enabling switchdev mode 2nd time:\n\nmlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload\nBUG: kernel NULL pointer dereference, address: 0000000000000038\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_detach_netdev+0x3c/0x90\nCode: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 \u0026lt;48\u0026gt; 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07\nRSP: 0018:ffffc90000673890 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000\nRDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000\nR10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000\nR13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000\nFS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_netdev_change_profile+0x45/0xb0\n mlx5e_vport_rep_load+0x27b/0x2d0\n mlx5_esw_offloads_rep_load+0x72/0xf0\n esw_offloads_enable+0x5d0/0x970\n mlx5_eswitch_enable_locked+0x349/0x430\n ? is_mp_supported+0x57/0xb0\n mlx5_devlink_eswitch_mode_set+0x26b/0x430\n devlink_nl_eswitch_set_doit+0x6f/0xf0\n genl_family_rcv_msg_doit+0xe8/0x140\n genl_rcv_msg+0x18b/0x290\n ? __pfx_devlink_nl_pre_doit+0x10/0x10\n ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10\n ? __pfx_devlink_nl_post_doit+0x10/0x10\n ? __pfx_genl_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x52/0x100\n genl_rcv+0x28/0x40\n netlink_unicast+0x282/0x3e0\n ? __alloc_skb+0xd6/0x190\n netlink_sendmsg+0x1f7/0x430\n __sys_sendto+0x213/0x220\n ? __sys_recvmsg+0x6a/0xd0\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fdfb8495047(CVE-2026-23000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1\n\nWhen loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in\nresponse to a guest WRMSR, clear XFD-disabled features in the saved (or to\nbe restored) XSTATE_BV to ensure KVM doesn\u0026apos;t attempt to load state for\nfeatures that are disabled via the guest\u0026apos;s XFD. Because the kernel\nexecutes XRSTOR with the guest\u0026apos;s XFD, saving XSTATE_BV[i]=1 with XFD[i]=1\nwill cause XRSTOR to #NM and panic the kernel.\n\nE.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:\n\n ------------[ cut here ]------------\n WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:exc_device_not_available+0x101/0x110\n Call Trace:\n \u0026lt;TASK\u0026gt;\n asm_exc_device_not_available+0x1a/0x20\n RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n switch_fpu_return+0x4a/0xb0\n kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]\n kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n __x64_sys_ioctl+0x8f/0xd0\n do_syscall_64+0x62/0x940\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nThis can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,\nand a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler\u0026apos;s\ncall to fpu_update_guest_xfd().\n\nand if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:\n\n ------------[ cut here ]------------\n WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:exc_device_not_available+0x101/0x110\n Call Trace:\n \u0026lt;TASK\u0026gt;\n asm_exc_device_not_available+0x1a/0x20\n RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n fpu_swap_kvm_fpstate+0x6b/0x120\n kvm_load_guest_fpu+0x30/0x80 [kvm]\n kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]\n kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n __x64_sys_ioctl+0x8f/0xd0\n do_syscall_64+0x62/0x940\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nThe new behavior is consistent with the AMX architecture. Per Intel\u0026apos;s SDM,\nXSAVE saves XSTATE_BV as \u0026apos;0\u0026apos; for components that are disabled via XFD\n(and non-compacted XSAVE saves the initial configuration of the state\ncomponent):\n\n If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,\n the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;\n instead, it operates as if XINUSE[i] = 0 (and the state component was\n in its initial state): it saves bit i of XSTATE_BV field of the XSAVE\n header as 0; in addition, XSAVE saves the initial configuration of the\n state component (the other instructions do not save state component i).\n\nAlternatively, KVM could always do XRSTOR with XFD=0, e.g. by using\na constant XFD based on the set of enabled features when XSAVEing for\na struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled\nfeatures can only happen in the above interrupt case, or in similar\nscenarios involving preemption on preemptible kernels, because\nfpu_swap_kvm_fpstate()\u0026apos;s call to save_fpregs_to_fpstate() saves the\noutgoing FPU state with the current XFD; and that is (on all but the\nfirst WRMSR to XFD) the guest XFD.\n\nTherefore, XFD can only go out of sync with XSTATE_BV in the above\ninterrupt case, or in similar scenarios involving preemption on\npreemptible kernels, and it we can consider it (de facto) part of KVM\nABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.\n\n[Move clea\n---truncated---(CVE-2026-23005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails.\n\nPass netdev to mlx5e_destroy_netdev() to guarantee it will work on a\nvalid netdev.\n\nOn mlx5e_remove: Check validity of priv-\u0026gt;profile, before attempting\nto cleanup any resources that might be not there.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \u0026quot;mlx5e\u0026quot;: -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==\u0026gt; oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000370\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100\nRSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286\nRAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0\nRBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10\nR10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0\nR13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400\nFS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlx5e_remove+0x57/0x110\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140(CVE-2026-23035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add recursion protection in kernel stack trace recording\n\nA bug was reported about an infinite recursion caused by tracing the rcu\nevents with the kernel stack trace trigger enabled. The stack trace code\ncalled back into RCU which then called the stack trace again.\n\nExpand the ftrace recursion protection to add a set of bits to protect\nevents from recursion. Each bit represents the context that the event is\nin (normal, softirq, interrupt and NMI).\n\nHave the stack trace code use the interrupt context to protect against\nrecursion.\n\nNote, the bug showed an issue in both the RCU code as well as the tracing\nstacktrace code. This only handles the tracing stack trace side of the\nbug. The RCU fix will be handled separately.(CVE-2026-23138)",
"id": "OESA-2026-1761",
"modified": "2026-08-06T11:10:47Z",
"published": "2026-03-27T11:10:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1761"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38373"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38659"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40030"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40215"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40220"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40242"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40251"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40272"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40277"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40294"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40308"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40318"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40341"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40343"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40346"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40351"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40358"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40359"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40361"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68173"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68174"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68188"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68200"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68206"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68208"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68235"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68264"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68297"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68331"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68337"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68349"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68354"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68362"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68363"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68376"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71116"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71147"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23138"
}
],
"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-2024-53232",
"CVE-2025-37900",
"CVE-2025-37954",
"CVE-2025-38083",
"CVE-2025-38373",
"CVE-2025-38556",
"CVE-2025-38591",
"CVE-2025-38659",
"CVE-2025-38730",
"CVE-2025-39713",
"CVE-2025-39961",
"CVE-2025-40030",
"CVE-2025-40096",
"CVE-2025-40215",
"CVE-2025-40220",
"CVE-2025-40237",
"CVE-2025-40242",
"CVE-2025-40251",
"CVE-2025-40271",
"CVE-2025-40272",
"CVE-2025-40277",
"CVE-2025-40294",
"CVE-2025-40301",
"CVE-2025-40308",
"CVE-2025-40318",
"CVE-2025-40341",
"CVE-2025-40342",
"CVE-2025-40343",
"CVE-2025-40346",
"CVE-2025-40351",
"CVE-2025-40358",
"CVE-2025-40359",
"CVE-2025-40361",
"CVE-2025-68171",
"CVE-2025-68173",
"CVE-2025-68174",
"CVE-2025-68176",
"CVE-2025-68188",
"CVE-2025-68200",
"CVE-2025-68206",
"CVE-2025-68208",
"CVE-2025-68235",
"CVE-2025-68259",
"CVE-2025-68261",
"CVE-2025-68264",
"CVE-2025-68265",
"CVE-2025-68297",
"CVE-2025-68301",
"CVE-2025-68309",
"CVE-2025-68331",
"CVE-2025-68337",
"CVE-2025-68349",
"CVE-2025-68354",
"CVE-2025-68356",
"CVE-2025-68362",
"CVE-2025-68363",
"CVE-2025-68376",
"CVE-2025-68378",
"CVE-2025-68724",
"CVE-2025-68725",
"CVE-2025-68734",
"CVE-2025-68741",
"CVE-2025-68744",
"CVE-2025-68745",
"CVE-2025-68756",
"CVE-2025-68780",
"CVE-2025-68782",
"CVE-2025-68794",
"CVE-2025-68803",
"CVE-2025-68814",
"CVE-2025-68816",
"CVE-2025-68818",
"CVE-2025-71072",
"CVE-2025-71104",
"CVE-2025-71116",
"CVE-2025-71131",
"CVE-2025-71147",
"CVE-2025-71149",
"CVE-2025-71150",
"CVE-2026-22996",
"CVE-2026-22998",
"CVE-2026-23000",
"CVE-2026-23005",
"CVE-2026-23035",
"CVE-2026-23138"
]
}
OPENSUSE-SU-2026:20145-1
Vulnerability from csaf_opensuse - Published: 2026-02-02 11:54 - Updated: 2026-09-17 17:26RHSA-2026:1661
Vulnerability from csaf_redhat - Published: 2026-02-02 03:27 - Updated: 2026-09-16 19:09A flaw was found in the Linux kernel. This use-after-free (UAF) vulnerability occurs in the `proc_readdir_de()` function within the `/proc` filesystem. A local attacker with low privileges can exploit this by concurrently traversing specific directories while network devices are unregistered. This can lead to a use-after-free condition, potentially resulting in information disclosure, privilege escalation, or a denial of service (DoS).
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.