Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-23063 (GCVE-0-2026-23063)
Vulnerability from cvelistv5 – Published: 2026-02-04 16:07 – Updated: 2026-05-11 21:59| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
015d239ac0142ad0e26567fd890ef8d171f13709 , < b457abeb5d962db88aaf60e249402fd3073dbfab
(git)
Affected: 015d239ac0142ad0e26567fd890ef8d171f13709 , < 8b57bf1d3b1db692f34bce694a03e41be79f6016 (git) Affected: 015d239ac0142ad0e26567fd890ef8d171f13709 , < 336fb41a186e7c0415ae94fec9e23d1f04b87483 (git) Affected: 015d239ac0142ad0e26567fd890ef8d171f13709 , < 43f233eb6e7b9d88536881a9bc43726d0e34800d (git) Affected: 015d239ac0142ad0e26567fd890ef8d171f13709 , < 47634d70073890c9c37e39ab4ff93d4b585b028a (git) Affected: 015d239ac0142ad0e26567fd890ef8d171f13709 , < 92e4f11e29b98ef424ff72d6371acac03e5d973c (git) Affected: 015d239ac0142ad0e26567fd890ef8d171f13709 , < 26c08dabe5475d99a13f353d8dd70e518de45663 (git) |
guessed | |
| Linux | Linux |
Affected:
5.7
Unaffected: 0 , < 5.7 (semver) Unaffected: 5.10.249 , ≤ 5.10.* (semver) Unaffected: 5.15.199 , ≤ 5.15.* (semver) Unaffected: 6.1.162 , ≤ 6.1.* (semver) Unaffected: 6.6.122 , ≤ 6.6.* (semver) Unaffected: 6.12.68 , ≤ 6.12.* (semver) Unaffected: 6.18.8 , ≤ 6.18.* (semver) Unaffected: 6.19 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/misc/uacce/uacce.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b457abeb5d962db88aaf60e249402fd3073dbfab",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "8b57bf1d3b1db692f34bce694a03e41be79f6016",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "336fb41a186e7c0415ae94fec9e23d1f04b87483",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "43f233eb6e7b9d88536881a9bc43726d0e34800d",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "47634d70073890c9c37e39ab4ff93d4b585b028a",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "92e4f11e29b98ef424ff72d6371acac03e5d973c",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "26c08dabe5475d99a13f353d8dd70e518de45663",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/misc/uacce/uacce.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.7"
},
{
"lessThan": "5.7",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.249",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.199",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.162",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.122",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.68",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.249",
"versionStartIncluding": "5.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.199",
"versionStartIncluding": "5.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.162",
"versionStartIncluding": "5.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.122",
"versionStartIncluding": "5.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.68",
"versionStartIncluding": "5.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.8",
"versionStartIncluding": "5.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "5.7",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nuacce: ensure safe queue release with state management\n\nDirectly calling `put_queue` carries risks since it cannot\nguarantee that resources of `uacce_queue` have been fully released\nbeforehand. So adding a `stop_queue` operation for the\nUACCE_CMD_PUT_Q command and leaving the `put_queue` operation to\nthe final resource release ensures safety.\n\nQueue states are defined as follows:\n- UACCE_Q_ZOMBIE: Initial state\n- UACCE_Q_INIT: After opening `uacce`\n- UACCE_Q_STARTED: After `start` is issued via `ioctl`\n\nWhen executing `poweroff -f` in virt while accelerator are still\nworking, `uacce_fops_release` and `uacce_remove` may execute\nconcurrently. This can cause `uacce_put_queue` within\n`uacce_fops_release` to access a NULL `ops` pointer. Therefore, add\nstate checks to prevent accessing freed pointers."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:59:17.047Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b457abeb5d962db88aaf60e249402fd3073dbfab"
},
{
"url": "https://git.kernel.org/stable/c/8b57bf1d3b1db692f34bce694a03e41be79f6016"
},
{
"url": "https://git.kernel.org/stable/c/336fb41a186e7c0415ae94fec9e23d1f04b87483"
},
{
"url": "https://git.kernel.org/stable/c/43f233eb6e7b9d88536881a9bc43726d0e34800d"
},
{
"url": "https://git.kernel.org/stable/c/47634d70073890c9c37e39ab4ff93d4b585b028a"
},
{
"url": "https://git.kernel.org/stable/c/92e4f11e29b98ef424ff72d6371acac03e5d973c"
},
{
"url": "https://git.kernel.org/stable/c/26c08dabe5475d99a13f353d8dd70e518de45663"
}
],
"title": "uacce: ensure safe queue release with state management",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23063",
"datePublished": "2026-02-04T16:07:45.426Z",
"dateReserved": "2026-01-13T15:37:45.953Z",
"dateUpdated": "2026-05-11T21:59:17.047Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-23063",
"date": "2026-09-17",
"epss": "0.00128",
"percentile": "0.0278"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2026-23063\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-02-04T17:16:16.987\",\"lastModified\":\"2026-06-17T10:20:47.797\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nuacce: ensure safe queue release with state management\\n\\nDirectly calling `put_queue` carries risks since it cannot\\nguarantee that resources of `uacce_queue` have been fully released\\nbeforehand. So adding a `stop_queue` operation for the\\nUACCE_CMD_PUT_Q command and leaving the `put_queue` operation to\\nthe final resource release ensures safety.\\n\\nQueue states are defined as follows:\\n- UACCE_Q_ZOMBIE: Initial state\\n- UACCE_Q_INIT: After opening `uacce`\\n- UACCE_Q_STARTED: After `start` is issued via `ioctl`\\n\\nWhen executing `poweroff -f` in virt while accelerator are still\\nworking, `uacce_fops_release` and `uacce_remove` may execute\\nconcurrently. This can cause `uacce_put_queue` within\\n`uacce_fops_release` to access a NULL `ops` pointer. Therefore, add\\nstate checks to prevent accessing freed pointers.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\\n\\nuacce: asegurar la liberaci\u00f3n segura de la cola con gesti\u00f3n de estado\\n\\nLlamar directamente a \u0027put_queue\u0027 conlleva riesgos ya que no puede garantizar que los recursos de \u0027uacce_queue\u0027 hayan sido completamente liberados de antemano. Por lo tanto, a\u00f1adir una operaci\u00f3n \u0027stop_queue\u0027 para el comando UACCE_CMD_PUT_Q y dejar la operaci\u00f3n \u0027put_queue\u0027 para la liberaci\u00f3n final de recursos garantiza la seguridad.\\n\\nLos estados de la cola se definen de la siguiente manera:\\n- UACCE_Q_ZOMBIE: Estado inicial\\n- UACCE_Q_INIT: Despu\u00e9s de abrir \u0027uacce\u0027\\n- UACCE_Q_STARTED: Despu\u00e9s de que se emite \u0027start\u0027 a trav\u00e9s de \u0027ioctl\u0027\\n\\nAl ejecutar \u0027poweroff -f\u0027 en virt mientras el acelerador sigue funcionando, \u0027uacce_fops_release\u0027 y \u0027uacce_remove\u0027 pueden ejecutarse concurrentemente. Esto puede causar que \u0027uacce_put_queue\u0027 dentro de \u0027uacce_fops_release\u0027 acceda a un puntero \u0027ops\u0027 NULL. Por lo tanto, a\u00f1adir comprobaciones de estado para evitar acceder a punteros liberados.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/misc/uacce/uacce.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"015d239ac0142ad0e26567fd890ef8d171f13709\",\"lessThan\":\"b457abeb5d962db88aaf60e249402fd3073dbfab\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"015d239ac0142ad0e26567fd890ef8d171f13709\",\"lessThan\":\"8b57bf1d3b1db692f34bce694a03e41be79f6016\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"015d239ac0142ad0e26567fd890ef8d171f13709\",\"lessThan\":\"336fb41a186e7c0415ae94fec9e23d1f04b87483\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"015d239ac0142ad0e26567fd890ef8d171f13709\",\"lessThan\":\"43f233eb6e7b9d88536881a9bc43726d0e34800d\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"015d239ac0142ad0e26567fd890ef8d171f13709\",\"lessThan\":\"47634d70073890c9c37e39ab4ff93d4b585b028a\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"015d239ac0142ad0e26567fd890ef8d171f13709\",\"lessThan\":\"92e4f11e29b98ef424ff72d6371acac03e5d973c\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"015d239ac0142ad0e26567fd890ef8d171f13709\",\"lessThan\":\"26c08dabe5475d99a13f353d8dd70e518de45663\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/misc/uacce/uacce.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"5.7\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"5.7\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.249\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.199\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.162\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.122\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.68\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.18.8\",\"lessThanOrEqual\":\"6.18.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.19\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-476\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.7\",\"versionEndExcluding\":\"5.10.249\",\"matchCriteriaId\":\"5B635197-F169-4155-A953-A712BDD15376\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.199\",\"matchCriteriaId\":\"A247FBA6-BEB9-484F-B892-DD5517949CCD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.162\",\"matchCriteriaId\":\"6579E0D4-0641-479D-A4C3-0EF618798C55\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.122\",\"matchCriteriaId\":\"8EAAE395-0162-4BAF-9AD5-E9AF3C869C4F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.12.68\",\"matchCriteriaId\":\"52F38E19-0FDD-4992-9D6D-D4169D689598\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.13\",\"versionEndExcluding\":\"6.18.8\",\"matchCriteriaId\":\"E65C6E79-7EBE-4C77-93F0-818CF5B38F4E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"17B67AA7-40D6-4AFA-8459-F200F3D7CFD1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"C47E4CC9-C826-4FA9-B014-7FE3D9B318B2\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"F71D92C0-C023-48BD-B3B6-70B638EEE298\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"13580667-0A98-40CC-B29F-D12790B91BDB\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"CAD1FED7-CF48-47BF-AC7D-7B6FA3C065FC\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc6:*:*:*:*:*:*\",\"matchCriteriaId\":\"3EF854A1-ABB1-4E93-BE9A-44569EC76C0D\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/26c08dabe5475d99a13f353d8dd70e518de45663\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/336fb41a186e7c0415ae94fec9e23d1f04b87483\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/43f233eb6e7b9d88536881a9bc43726d0e34800d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/47634d70073890c9c37e39ab4ff93d4b585b028a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/8b57bf1d3b1db692f34bce694a03e41be79f6016\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/92e4f11e29b98ef424ff72d6371acac03e5d973c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b457abeb5d962db88aaf60e249402fd3073dbfab\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
"redhat_vex": {
"aggregate_severity": "None",
"current_release_date": "2026-06-28T07:18:30+00:00",
"cve": "CVE-2026-23063",
"id": "CVE-2026-23063",
"initial_release_date": "2026-02-04T00:00:00+00:00",
"product_status:known_not_affected": "274",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: uacce: ensure safe queue release with state management",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-23063.json",
"version": "3"
}
}
}
FKIE_CVE-2026-23063
Vulnerability from fkie_nvd - Published: 2026-02-04 17:16 - Updated: 2026-06-17 10:20| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.19 | |
| linux | linux_kernel | 6.19 | |
| linux | linux_kernel | 6.19 | |
| linux | linux_kernel | 6.19 | |
| linux | linux_kernel | 6.19 | |
| linux | linux_kernel | 6.19 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/misc/uacce/uacce.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b457abeb5d962db88aaf60e249402fd3073dbfab",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "8b57bf1d3b1db692f34bce694a03e41be79f6016",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "336fb41a186e7c0415ae94fec9e23d1f04b87483",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "43f233eb6e7b9d88536881a9bc43726d0e34800d",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "47634d70073890c9c37e39ab4ff93d4b585b028a",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "92e4f11e29b98ef424ff72d6371acac03e5d973c",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
},
{
"lessThan": "26c08dabe5475d99a13f353d8dd70e518de45663",
"status": "affected",
"version": "015d239ac0142ad0e26567fd890ef8d171f13709",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/misc/uacce/uacce.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.7"
},
{
"lessThan": "5.7",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.249",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.199",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.162",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.122",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.68",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5B635197-F169-4155-A953-A712BDD15376",
"versionEndExcluding": "5.10.249",
"versionStartIncluding": "5.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A247FBA6-BEB9-484F-B892-DD5517949CCD",
"versionEndExcluding": "5.15.199",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6579E0D4-0641-479D-A4C3-0EF618798C55",
"versionEndExcluding": "6.1.162",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8EAAE395-0162-4BAF-9AD5-E9AF3C869C4F",
"versionEndExcluding": "6.6.122",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "52F38E19-0FDD-4992-9D6D-D4169D689598",
"versionEndExcluding": "6.12.68",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E65C6E79-7EBE-4C77-93F0-818CF5B38F4E",
"versionEndExcluding": "6.18.8",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*",
"matchCriteriaId": "17B67AA7-40D6-4AFA-8459-F200F3D7CFD1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*",
"matchCriteriaId": "C47E4CC9-C826-4FA9-B014-7FE3D9B318B2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F71D92C0-C023-48BD-B3B6-70B638EEE298",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*",
"matchCriteriaId": "13580667-0A98-40CC-B29F-D12790B91BDB",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*",
"matchCriteriaId": "CAD1FED7-CF48-47BF-AC7D-7B6FA3C065FC",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc6:*:*:*:*:*:*",
"matchCriteriaId": "3EF854A1-ABB1-4E93-BE9A-44569EC76C0D",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nuacce: ensure safe queue release with state management\n\nDirectly calling `put_queue` carries risks since it cannot\nguarantee that resources of `uacce_queue` have been fully released\nbeforehand. So adding a `stop_queue` operation for the\nUACCE_CMD_PUT_Q command and leaving the `put_queue` operation to\nthe final resource release ensures safety.\n\nQueue states are defined as follows:\n- UACCE_Q_ZOMBIE: Initial state\n- UACCE_Q_INIT: After opening `uacce`\n- UACCE_Q_STARTED: After `start` is issued via `ioctl`\n\nWhen executing `poweroff -f` in virt while accelerator are still\nworking, `uacce_fops_release` and `uacce_remove` may execute\nconcurrently. This can cause `uacce_put_queue` within\n`uacce_fops_release` to access a NULL `ops` pointer. Therefore, add\nstate checks to prevent accessing freed pointers."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nuacce: asegurar la liberaci\u00f3n segura de la cola con gesti\u00f3n de estado\n\nLlamar directamente a \u0027put_queue\u0027 conlleva riesgos ya que no puede garantizar que los recursos de \u0027uacce_queue\u0027 hayan sido completamente liberados de antemano. Por lo tanto, a\u00f1adir una operaci\u00f3n \u0027stop_queue\u0027 para el comando UACCE_CMD_PUT_Q y dejar la operaci\u00f3n \u0027put_queue\u0027 para la liberaci\u00f3n final de recursos garantiza la seguridad.\n\nLos estados de la cola se definen de la siguiente manera:\n- UACCE_Q_ZOMBIE: Estado inicial\n- UACCE_Q_INIT: Despu\u00e9s de abrir \u0027uacce\u0027\n- UACCE_Q_STARTED: Despu\u00e9s de que se emite \u0027start\u0027 a trav\u00e9s de \u0027ioctl\u0027\n\nAl ejecutar \u0027poweroff -f\u0027 en virt mientras el acelerador sigue funcionando, \u0027uacce_fops_release\u0027 y \u0027uacce_remove\u0027 pueden ejecutarse concurrentemente. Esto puede causar que \u0027uacce_put_queue\u0027 dentro de \u0027uacce_fops_release\u0027 acceda a un puntero \u0027ops\u0027 NULL. Por lo tanto, a\u00f1adir comprobaciones de estado para evitar acceder a punteros liberados."
}
],
"id": "CVE-2026-23063",
"lastModified": "2026-06-17T10:20:47.797",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2026-02-04T17:16:16.987",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/26c08dabe5475d99a13f353d8dd70e518de45663"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/336fb41a186e7c0415ae94fec9e23d1f04b87483"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/43f233eb6e7b9d88536881a9bc43726d0e34800d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/47634d70073890c9c37e39ab4ff93d4b585b028a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/8b57bf1d3b1db692f34bce694a03e41be79f6016"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/92e4f11e29b98ef424ff72d6371acac03e5d973c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b457abeb5d962db88aaf60e249402fd3073dbfab"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-Q353-PRFJ-6JCP
Vulnerability from github – Published: 2026-02-04 18:30 – Updated: 2026-03-13 21:31In the Linux kernel, the following vulnerability has been resolved:
uacce: ensure safe queue release with state management
Directly calling put_queue carries risks since it cannot
guarantee that resources of uacce_queue have been fully released
beforehand. So adding a stop_queue operation for the
UACCE_CMD_PUT_Q command and leaving the put_queue operation to
the final resource release ensures safety.
Queue states are defined as follows:
- UACCE_Q_ZOMBIE: Initial state
- UACCE_Q_INIT: After opening uacce
- UACCE_Q_STARTED: After start is issued via ioctl
When executing poweroff -f in virt while accelerator are still
working, uacce_fops_release and uacce_remove may execute
concurrently. This can cause uacce_put_queue within
uacce_fops_release to access a NULL ops pointer. Therefore, add
state checks to prevent accessing freed pointers.
{
"affected": [],
"aliases": [
"CVE-2026-23063"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-04T17:16:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nuacce: ensure safe queue release with state management\n\nDirectly calling `put_queue` carries risks since it cannot\nguarantee that resources of `uacce_queue` have been fully released\nbeforehand. So adding a `stop_queue` operation for the\nUACCE_CMD_PUT_Q command and leaving the `put_queue` operation to\nthe final resource release ensures safety.\n\nQueue states are defined as follows:\n- UACCE_Q_ZOMBIE: Initial state\n- UACCE_Q_INIT: After opening `uacce`\n- UACCE_Q_STARTED: After `start` is issued via `ioctl`\n\nWhen executing `poweroff -f` in virt while accelerator are still\nworking, `uacce_fops_release` and `uacce_remove` may execute\nconcurrently. This can cause `uacce_put_queue` within\n`uacce_fops_release` to access a NULL `ops` pointer. Therefore, add\nstate checks to prevent accessing freed pointers.",
"id": "GHSA-q353-prfj-6jcp",
"modified": "2026-03-13T21:31:40Z",
"published": "2026-02-04T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23063"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26c08dabe5475d99a13f353d8dd70e518de45663"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/336fb41a186e7c0415ae94fec9e23d1f04b87483"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43f233eb6e7b9d88536881a9bc43726d0e34800d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47634d70073890c9c37e39ab4ff93d4b585b028a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b57bf1d3b1db692f34bce694a03e41be79f6016"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92e4f11e29b98ef424ff72d6371acac03e5d973c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b457abeb5d962db88aaf60e249402fd3073dbfab"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
oesa-2026-2417
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fakpm@linux-foundation.org: add unlikely()
In the Linux kernel, the following vulnerability has been resolved:
PCI/MSI: Handle lack of irqdomain gracefully
Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a RISCV platform which does not provide PCI/MSI support:
WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32 __pci_enable_msix_range+0x30c/0x596 pci_msi_setup_msi_irqs+0x2c/0x32 pci_alloc_irq_vectors_affinity+0xb8/0xe2
RISCV uses hierarchical interrupt domains and correctly does not implement the legacy fallback. The warning triggers from the legacy fallback stub.
That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent domain is associated with the device or not. There is a check for MSI-X, which has a legacy assumption. But that legacy fallback assumption is only valid when legacy support is enabled, but otherwise the check should simply return -ENOTSUPP.
Loongarch tripped over the same problem and blindly enabled legacy support without implementing the legacy fallbacks. There are weak implementations which return an error, so the problem was papered over.
Correct pci_msi_domain_supports() to evaluate the legacy mode and add the missing supported check into the MSI enable path to complete it.(CVE-2024-56760)
In the Linux kernel, the following vulnerability has been resolved:
NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback
Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.
Otherwise NFS can deadlock waiting for kcompactd enduced writeback which recurses back to NFS (which triggers writeback to NFSD via NFS loopback mount on the same host, NFSD blocks waiting for XFS's call to __filemap_get_folio):
6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.
{--- [58] "kcompactd0" [<0>] folio_wait_bit+0xe8/0x200 [<0>] folio_wait_writeback+0x2b/0x80 [<0>] nfs_wb_folio+0x80/0x1b0 [nfs] [<0>] nfs_release_folio+0x68/0x130 [nfs] [<0>] split_huge_page_to_list_to_order+0x362/0x840 [<0>] migrate_pages_batch+0x43d/0xb90 [<0>] migrate_pages_sync+0x9a/0x240 [<0>] migrate_pages+0x93c/0x9f0 [<0>] compact_zone+0x8e2/0x1030 [<0>] compact_node+0xdb/0x120 [<0>] kcompactd+0x121/0x2e0 [<0>] kthread+0xcf/0x100 [<0>] ret_from_fork+0x31/0x40 [<0>] ret_from_fork_asm+0x1a/0x30 ---}
[(CVE-2025-21908)
In the Linux kernel, the following vulnerability has been resolved:
hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio
Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page. However folio lock must be held before calling try_to_unmap. Add it to fix this problem.
Warning will be produced if folio is not locked during unmap:
------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---(CVE-2025-21931)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Bridge, fix the crash caused by LAG state check
When removing LAG device from bridge, NETDEV_CHANGEUPPER event is triggered. Driver finds the lower devices (PFs) to flush all the offloaded entries. And mlx5_lag_is_shared_fdb is checked, it returns false if one of PF is unloaded. In such case, mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead of the alive PF, and the flush is skipped.
Besides, the bridge fdb entry's lastuse is updated in mlx5 bridge event handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can be ignored in this case because the upper interface for bond is deleted, and the entry will never be aged because lastuse is never updated.
To make things worse, as the entry is alive, mlx5 bridge workqueue keeps sending that event, which is then handled by kernel bridge notifier. It causes the following crash when accessing the passed bond netdev which is already destroyed.
To fix this issue, remove such checks. LAG state is already checked in commit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when adding bond to bridge"), driver still need to skip offload if LAG becomes invalid state after initialization.
Oops: stack segment: 0000 [#1] SMP CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G OE 6.11.0_mlnx #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 </TASK>(CVE-2025-21970)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: Prevent creation of classes with TC_H_ROOT
The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho.
Prevent the creation of any Qdisc class with classid TC_H_ROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal.(CVE-2025-21971)
In the Linux kernel, the following vulnerability has been resolved:
sched: address a potential NULL pointer dereference in the GRED scheduler.
If kzalloc in gred_init returns a NULL pointer, the code follows the error handling path, invoking gred_destroy. This, in turn, calls gred_offload, where memset could receive a NULL pointer as input, potentially leading to a kernel crash.
When table->opt is NULL in gred_init(), gred_change_table_def() is not called yet, so it is not necessary to call ->ndo_setup_tc() in gred_offload().(CVE-2025-21980)
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:
net: switchdev: Convert blocking notification chain to a raw one
A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event.
In case of the blocking switchdev notification chain, recursive notifications are possible which leads to the semaphore being acquired twice for reading and to lockdep warnings being generated [1].
Specifically, this can happen when the bridge driver processes a SWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications about deferred events when calling switchdev_deferred_process().
Fix this by converting the notification chain to a raw notification chain in a similar fashion to the netdev notification chain. Protect the chain using the RTNL mutex by acquiring it when modifying the chain. Events are always informed under the RTNL mutex, but add an assertion in call_switchdev_blocking_notifiers() to make sure this is not violated in the future.
Maintain the "blocking" prefix as events are always emitted from process context and listeners are allowed to block.
[1]: WARNING: possible recursive locking detected 6.14.0-rc4-custom-g079270089484 #1 Not tainted
ip/52731 is trying to acquire lock: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0
but task is already holding lock: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0
other info that might help us debug this: Possible unsafe locking scenario: CPU0
lock((switchdev_blocking_notif_chain).rwsem); lock((switchdev_blocking_notif_chain).rwsem);
*** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by ip/52731: #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0 #1: ffffffff8731f628 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0 #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0
stack backtrace: ... ? __pfx_down_read+0x10/0x10 ? __pfx_mark_lock+0x10/0x10 ? __pfx_switchdev_port_attr_set_deferred+0x10/0x10 blocking_notifier_call_chain+0x58/0xa0 switchdev_port_attr_notify.constprop.0+0xb3/0x1b0 ? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10 ? mark_held_locks+0x94/0xe0 ? switchdev_deferred_process+0x11a/0x340 switchdev_port_attr_set_deferred+0x27/0xd0 switchdev_deferred_process+0x164/0x340 br_switchdev_port_unoffload+0xc8/0x100 [bridge] br_switchdev_blocking_event+0x29f/0x580 [bridge] notifier_call_chain+0xa2/0x440 blocking_notifier_call_chain+0x6e/0xa0 switchdev_bridge_port_unoffload+0xde/0x1a0 ...(CVE-2025-21986)
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Fix fence reference count leak
The last_scheduled fence leaks when an entity is being killed and adding the cleanup callback fails.
Decrement the reference count of prev when dma_fence_add_callback() fails, ensuring proper balance.
phasta: add git tag info for stable kernel
In the Linux kernel, the following vulnerability has been resolved:
accel/qaic: Fix integer overflow in qaic_validate_req()
These are u64 variables that come from the user via qaic_attach_slice_bo_ioctl(). Use check_add_overflow() to ensure that the math doesn't have an integer wrapping bug.(CVE-2025-22001)
In the Linux kernel, the following vulnerability has been resolved:
regulator: dummy: force synchronous probing
Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack:
anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get()
By placing some extra BUG_ON() statements I could verify that this is raised because probing of the 'dummy' regulator driver is not completed ('dummy_regulator_rdev' is still NULL).
In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven't further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don't expect much boot time penalty by probing the 'dummy' regulator synchronously.(CVE-2025-22009)
In the Linux kernel, the following vulnerability has been resolved:
spufs: fix a leak in spufs_create_context()
Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufs_mkdir() fails, we need to drop the reference to neighbor.(CVE-2025-22071)
In the Linux kernel, the following vulnerability has been resolved:
Revert "smb: client: fix TCP timers deadlock after rmmod"
This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.
Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is mentioned as CVE-2024-54680, but is actually did not fix anything; The issue can be reproduced on top of it. [0]
Also, it reverted the change by commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") and introduced a real issue by reviving the kernel TCP socket.
When a reconnect happens for a CIFS connection, the socket state transitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync() in tcp_close() stops all timers for the socket.
If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1 forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.
Usually, FIN can be retransmitted by the peer, but if the peer aborts the connection, the issue comes into reality.
I warned about this privately by pointing out the exact report [1], but the bogus fix was finally merged.
So, we should not stop the timers to finally kill the connection on our side in that case, meaning we must not use a kernel socket for TCP whose sk->sk_net_refcnt is 0.
The kernel socket does not have a reference to its netns to make it possible to tear down netns without cleaning up every resource in it.
For example, tunnel devices use a UDP socket internally, but we can destroy netns without removing such devices and let it complete during exit. Otherwise, netns would be leaked when the last application died.
However, this is problematic for TCP sockets because TCP has timers to close the connection gracefully even after the socket is close()d. The lifetime of the socket and its netns is different from the lifetime of the underlying connection.
If the socket user does not maintain the netns lifetime, the timer could be fired after the socket is close()d and its netns is freed up, resulting in use-after-free.
Actually, we have seen so many similar issues and converted such sockets to have a reference to netns.
That's why I converted the CIFS client socket to have a reference to netns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope of CIFS and technically wrong in e9f2517a3e18, but is in-scope and right fix.
Regarding the LOCKDEP issue, we can prevent the module unload by bumping the module refcount when switching the LOCKDDEP key in sock_lock_init_class_and_name(). [2]
For a while, let's revert the bogus fix.
Note that now we can use sk_net_refcnt_upgrade() for the socket conversion, but I'll do so later separately to make backport easy.(CVE-2025-22077)
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:
media: venus: hfi_parser: add check to avoid out of bound access
There is a possibility that init_codecs is invoked multiple times during manipulated payload from video firmware. In such case, if codecs_count can get incremented to value more than MAX_CODEC_NUM, there can be OOB access. Reset the count so that it always starts from beginning.(CVE-2025-23157)
In the Linux kernel, the following vulnerability has been resolved:
jfs: add sanity check for agwidth in dbMount
The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG.
To avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)
In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group
Currently, mtk_iommu calls during probe iommu_device_register before the hw_list from driver data is initialized. Since iommu probing issue fix, it leads to NULL pointer dereference in mtk_iommu_device_group when hw_list is accessed with list_first_entry (not null safe).
So, change the call order to ensure iommu_device_register is called after the driver data are initialized.(CVE-2025-37748)
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-37768)
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:
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-37771)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Fix dangling pointer in krb_authenticate
krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.(CVE-2025-37778)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()
devm_kasprintf() returns NULL when memory allocation fails. Currently, avs_component_probe() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37793)
In the Linux kernel, the following vulnerability has been resolved:
sound/virtio: Fix cancel_sync warnings on uninitialized work_structs
Betty reported hitting the following warning:
[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc [ 8.713570][ T221] cancel_work_sync+0x24/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390 [ 8.714139][ T221] really_probe+0x1bc/0x4c8 ...
It seems we're hitting the error path in virtsnd_probe(), which triggers a virtsnd_remove() which iterates over the substreams calling cancel_work_sync() on the elapsed_period work_struct.
Looking at the code, from earlier in: virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg()
We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsnd_ctl_query_info() fails, we will exit without having initialized the elapsed_period work_struct.
When that error path unwinds we then call virtsnd_remove() which as long as the substreams array is allocated, will iterate through calling cancel_work_sync() on the uninitialized work struct hitting this warning.
Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data.
Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing.
Feedback or thoughts would be appreciated!(CVE-2025-37805)
In the Linux kernel, the following vulnerability has been resolved:
misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration
Resolve kernel panic while accessing IRQ handler associated with the generated IRQ. This is done by acquiring the spinlock and storing the current interrupt state before handling the interrupt request using generic_handle_irq.
A previous fix patch was submitted where 'generic_handle_irq' was replaced with 'handle_nested_irq'. However, this change also causes the kernel panic where after determining which GPIO triggered the interrupt and attempting to call handle_nested_irq with the mapped IRQ number, leads to a failure in locating the registered handler.(CVE-2025-37815)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()
cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. apple_soc_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37831)
In the Linux kernel, the following vulnerability has been resolved:
cifs: avoid NULL pointer dereference in dbg call
cifs_server_dbg() implies server to be non-NULL so move call under condition to avoid NULL pointer dereference.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37844)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: debugfs hang_hws skip GPU with MES
debugfs hang_hws is used by GPU reset test with HWS, for MES this crash the kernel with NULL pointer access because dqm->packet_mgr is not setup for MES path.
Skip GPU with MES for now, MES hang_hws debugfs interface will be supported later.(CVE-2025-37853)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()
The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c").
This issue is found by our static analysis tool(CVE-2025-37881)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Consistently treat platform_max as control value
This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates.
There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to consistently use this interpretation of platform_max.
Finally, also add some comments to the soc_mixer_control struct to hopefully avoid further patches switching between the two approaches.(CVE-2025-37889)
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Balance device refcount when destroying devices
Using device_find_child() to lookup the proper SCMI device to destroy causes an unbalance in device refcount, since device_find_child() calls an implicit get_device(): this, in turns, inhibits the call of the provided release methods upon devices destruction.
As a consequence, one of the structures that is not freed properly upon destruction is the internal struct device_private dev->p populated by the drivers subsystem core.
KMemleak detects this situation since loading/unloding some SCMI driver causes related devices to be created/destroyed without calling any device_release method.
unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158
$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0 device_add+0x954/0x12d0: kmalloc_noprof at include/linux/slab.h:901 (inlined by) kzalloc_noprof at include/linux/slab.h:1037 (inlined by) device_private_init at drivers/base/core.c:3510 (inlined by) device_add at drivers/base/core.c:3561
Balance device refcount by issuing a put_device() on devices found via device_find_child().(CVE-2025-37905)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()
A NULL pointer dereference can occur in skb_dequeue() when processing a QCA firmware crash dump on WCN7851 (0489:e0f3).
[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)
[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth] [ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80
The issue stems from handle_dump_pkt_qca() returning 0 even when a dump packet is successfully processed. This is because it incorrectly forwards the return value of hci_devcd_init() (which returns 0 on success). As a result, the caller (btusb_recv_acl_qca() or btusb_recv_evt_qca()) assumes the packet was not handled and passes it to hci_recv_frame(), leading to premature kfree() of the skb.
Later, hci_devcd_rx() attempts to dequeue the same skb from the dump queue, resulting in a NULL pointer dereference.
Fix this by: 1. Making handle_dump_pkt_qca() return 0 on success and negative errno on failure, consistent with kernel conventions. 2. Splitting dump packet detection into separate functions for ACL and event packets for better structure and readability.
This ensures dump packets are properly identified and consumed, avoiding double handling and preventing NULL pointer access.(CVE-2025-37918)
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:
usb: typec: ucsi: displayport: Fix deadlock
This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it.(CVE-2025-37967)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Refactor remove call with idxd_cleanup() helper
The idxd_cleanup() helper cleans up perfmon, interrupts, internals and so on. Refactor remove call with the idxd_cleanup() helper to avoid code duplication. Note, this also fixes the missing put_device() for idxd groups, enginces and wqs.(CVE-2025-38014)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Annotate FDB data races
The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2].
Suppress these reports by annotating these accesses using READ_ONCE() / WRITE_ONCE().
[1] BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit
write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f
Reported by Kernel Concurrency Sanitizer on: CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[2] #!/bin/bash
set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan
ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &(CVE-2025-38037)
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_ffa: Set dma_mask for ffa devices
Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning:
WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124(CVE-2025-38043)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free in cifs_fill_dirent
There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning.
================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975
CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK>
Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30
Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================
POC is available in the link [1].
The problem triggering process is as follows:
Process 1 Process 2
---truncated---(CVE-2025-38051)
In the Linux kernel, the following vulnerability has been resolved:
virtio: break and reset virtio devices on device_shutdown()
Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory accesses during the hang.
Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected
Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected
...
It was traced down to virtio-console. Kexec works fine if virtio-console is not in use.
The issue is that virtio-console continues to write to the MMIO even after underlying virtio-pci device is reset.
Additionally, Eric noticed that IOMMUs are reset before devices, if devices are not reset on shutdown they continue to poke at guest memory and get errors from the IOMMU. Some devices get wedged then.
The problem can be solved by breaking all virtio devices on virtio bus shutdown, then resetting them.(CVE-2025-38064)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Fix NULL pointer dereference when nosmp is used
With nosmp in cmdline, other CPUs are not brought up, leaving their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu() dereferences these NULL pointers, causing panic.
Panic backtrace:
[ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8 ... [ 0.403255] [<ffffffff809a5818>] cppc_allow_fast_switch+0x6a/0xd4 ... Kernel panic - not syncing: Attempted to kill init!
In the Linux kernel, the following vulnerability has been resolved:
gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO
gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo() did not check for this case before dereferencing the returned pointer.
Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails.
This improves robustness in low-memory scenarios.(CVE-2025-38122)
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: t7xx: Fix napi rx poll issue
When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic.
BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:dev_gro_receive+0x3a/0x620 [...] Call Trace: <IRQ> ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)] ? dev_gro_receive+0x3a/0x620 napi_gro_receive+0xad/0x170 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)] t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)] net_rx_action+0x103/0x470 irq_exit_rcu+0x13a/0x310 sysvec_apic_timer_interrupt+0x56/0x90 </IRQ>(CVE-2025-38123)
In the Linux kernel, the following vulnerability has been resolved:
coresight: prevent deactivate active config while enabling the config
While enable active config via cscfg_csdev_enable_active_config(), active config could be deactivated via configfs' sysfs interface. This could make UAF issue in below scenario:
CPU0 CPU1 (sysfs enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock)
deactivate config // sysfs
(sys_activec_cnt == 0)
cscfg_unload_config_sets()
unload module
// access to config_desc which freed // while unloading module. cscfg_csdev_enable_config
To address this, use cscfg_config_desc's active_cnt as a reference count which will be holded when - activate the config. - enable the activated config. and put the module reference when config_active_cnt == 0.(CVE-2025-38131)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: mscc: Fix memory leak when using one step timestamping
Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping.(CVE-2025-38148)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction
Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure.
Now properly rollback the object to its original state upon such failure.
In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8(CVE-2025-38161)
In the Linux kernel, the following vulnerability has been resolved:
net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get()
Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8). This seems correct and aligns with the PTP interrupt status register (PTP_INT_STS) specifications.
However, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index:
lan743x_ptp_io_event_clock_get(..., u8 channel,...)
{
...
/* Update Local timestamp */
extts = &ptp->extts[channel];
extts->ts.tv_sec = sec;
...
}
To avoid an out-of-bounds write and utilize all the supported GPIO inputs, set LAN743X_PTP_N_EXTTS to 8.
Detected using the static analysis tool - Svace.(CVE-2025-38183)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: reject invalid perturb period
Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch.
We want to make sure ctl->perturb_period * HZ will not overflow and is positive.
tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period.
tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period.
tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0(CVE-2025-38193)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: check that raw node were preallocated before writing summary
Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't check return value of jffs2_prealloc_raw_node_refs and simply lets any error propagate into jffs2_sum_write_data, which eventually calls jffs2_link_node_ref in order to link the summary to an expectedly allocated node.
kernel BUG at fs/jffs2/nodelist.c:592! invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592 Call Trace: <TASK> jffs2_sum_write_data fs/jffs2/summary.c:841 [inline] jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005 call_write_iter include/linux/fs.h:2265 [inline] do_iter_readv_writev+0x20f/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+0x10c/0x170 fs/splice.c:950 splice_direct_to_actor+0x337/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
Fix this issue by checking return value of jffs2_prealloc_raw_node_refs before calling jffs2_sum_write_data.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38194)
In the Linux kernel, the following vulnerability has been resolved:
mm/shmem, swap: fix softlockup with mTHP swapin
Following softlockup can be easily reproduced on my test machine with:
echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled swapon /dev/zram0 # zram0 is a 48G swap device mkdir -p /sys/fs/cgroup/memory/test echo 1G > /sys/fs/cgroup/test/memory.max echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs while true; do dd if=/dev/zero of=/tmp/test.img bs=1M count=5120 cat /tmp/test.img > /dev/null rm /tmp/test.img done
Then after a while: watchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787] Modules linked in: zram virtiofs CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)· Tainted: [L]=SOFTLOCKUP Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 RIP: 0010:mpol_shared_policy_lookup+0xd/0x70 Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8 RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202 RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001 RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518 RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000 FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> shmem_alloc_folio+0x31/0xc0 shmem_swapin_folio+0x309/0xcf0 ? filemap_get_entry+0x117/0x1e0 ? xas_load+0xd/0xb0 ? filemap_get_entry+0x101/0x1e0 shmem_get_folio_gfp+0x2ed/0x5b0 shmem_file_read_iter+0x7f/0x2e0 vfs_read+0x252/0x330 ksys_read+0x68/0xf0 do_syscall_64+0x4c/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f03f9a46991 Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991 RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003 RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000 </TASK>
The reason is simple, readahead brought some order 0 folio in swap cache, and the swapin mTHP folio being allocated is in conflict with it, so swapcache_prepare fails and causes shmem_swap_alloc_folio to return -EEXIST, and shmem simply retries again and again causing this loop.
Fix it by applying a similar fix for anon mTHP swapin.
The performance change is very slight, time of swapin 10g zero folios with shmem (test for 12 times): Before: 2.47s After: 2.48s
[(CVE-2025-38241)
In the Linux kernel, the following vulnerability has been resolved:
lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()
While testing null_blk with configfs, echo 0 > poll_queues will trigger following panic:
BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__bitmap_or+0x48/0x70 Call Trace: <TASK> __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Root cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from kcalloc(), and later ZERO_SIZE_PTR will be deferenced.
Fix the problem by checking numgrps first in group_cpus_evenly(), and return NULL directly if numgrps is zero.
[(CVE-2025-38255)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix NULL pointer deference on eir_get_service_data
The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA.(CVE-2025-38304)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Verify content returned by parse_int_array()
The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref.(CVE-2025-38307)
In the Linux kernel, the following vulnerability has been resolved:
smb: Log an error when close_all_cached_dirs fails
Under low-memory conditions, close_all_cached_dirs() can't move the dentries to a separate list to dput() them once the locks are dropped. This will result in a "Dentry still in use" error, so add an error message that makes it clear this is what happened:
[ 495.281119] CIFS: VFS: \otters.example.com\share Out of memory while dropping dentries [ 495.281595] ------------[ cut here ]------------ [ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs] [ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0
Also, bail out of looping through all tcons as soon as a single allocation fails, since we're already in trouble, and kmalloc() attempts for subseqeuent tcons are likely to fail just like the first one did.(CVE-2025-38321)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: fix acpi parse and parseext cache leaks
ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5
I'm Seunghun Han, and I work for National Security Research Institute of South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases.
Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30
I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size.
I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function.
Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncated---(CVE-2025-38344)
In the Linux kernel, the following vulnerability has been resolved:
maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()
Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations.
The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption.
User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least)(CVE-2025-38364)
In the Linux kernel, the following vulnerability has been resolved:
vsock: Fix transport_* TOCTOU
Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer.
This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert.
BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38461)
In the Linux kernel, the following vulnerability has been resolved:
vsock: Fix transport_{g2h,h2g} TOCTOU
vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload. transport_{g2h,h2g} may become NULL after the NULL check.
Introduce vsock_transport_local_cid() to protect from a potential null-ptr-deref.
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_find_cid+0x47/0x90 Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0 Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38462)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in crypt_message when using async crypto
The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:
crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req);
// Async encryption returns -EINPROGRESS immediately
rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);
// Free creq while async operation is still in progress
kvfree_sensitive(creq, ...);
Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.
This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.
The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.
Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for async completion notification - crypto_wait_req() to wait for operation completion
This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.(CVE-2025-38488)
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:
mptcp: plug races between subflow fail and subflow creation
We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger.
The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock.
The socket fallback makes such flag true, and also receiving or sending an MP_FAIL option.
The field 'allow_infinite_fallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.(CVE-2025-38552)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use aead_request_free to match aead_request_alloc
Use aead_request_free() instead of kfree() to properly free memory allocated by aead_request_alloc(). This ensures sensitive crypto data is zeroed before being freed.(CVE-2025-38575)
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Check governor before using governor->name
Commit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq") removes governor_name and uses governor->name to replace it. But devfreq->governor may be NULL and directly using devfreq->governor->name may cause null pointer exception. Move the check of governor to before using governor->name.(CVE-2025-38609)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: fix refcount leak on table dump
There is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...
While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.
This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.
This will then block the netns dismantle (or conntrack rmmod) as nf_conntrack_cleanup_net_list() will wait forever.
This can be reproduced by running conntrack_resize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.
One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general);
But this reference counting isn't needed in the first place. We can just store a cookie value instead.
A followup patch will do the same for ctnetlink_exp_dump_table, it looks to me as if this has the same problem and like ctnetlink_dump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.(CVE-2025-38721)
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:
tls: fix handling of zero-length records on the rx_list
Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record
If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there.
Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).
Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length.(CVE-2025-39682)
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:
clk: samsung: Fix UBSAN panic in samsung_clk_init()
With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to
dereferencing ctx->clk_data.hws before setting
ctx->clk_data.num = nr_clks. Move that up to fix the crash.
UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP <snip> Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...(CVE-2025-39728)
In the Linux kernel, the following vulnerability has been resolved:
fs: Prevent file descriptor table allocations exceeding INT_MAX
When sysctl_nr_open is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c:
WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288
This happens because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning when the allocation is not flagged with __GFP_NOWARN.
Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)
Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open
- Run a program that uses a high file descriptor: #include <unistd.h> #include <sys/resource.h>
int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }
- Observe WARNING in dmesg at mm/slub.c:5027
systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that:
- The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting
- Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations
- The resulting allocations (>8GB) are impractical and will always fail
systemd's algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems, this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors.
While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue.
Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.(CVE-2025-39756)
In the Linux kernel, the following vulnerability has been resolved:
net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM
When performing Generic Segmentation Offload (GSO) on an IPv6 packet that contains extension headers, the kernel incorrectly requests checksum offload if the egress device only advertises NETIF_F_IPV6_CSUM feature, which has a strict contract: it supports checksum offload only for plain TCP or UDP over IPv6 and explicitly does not support packets with extension headers. The current GSO logic violates this contract by failing to disable the feature for packets with extension headers, such as those used in GREoIPv6 tunnels.
This violation results in the device being asked to perform an operation
it cannot support, leading to a skb_warn_bad_offload warning and a collapse
of network throughput. While device TSO/USO is correctly bypassed in favor
of software GSO for these packets, the GSO stack must be explicitly told not
to request checksum offload.
Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4 in gso_features_check if the IPv6 header contains extension headers to compute checksum in software.
The exception is a BIG TCP extension, which, as stated in commit 68e068cabd2c6c53 ("net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets"): "The feature is only enabled on devices that support BIG TCP TSO. The header is only present for PF_PACKET taps like tcpdump, and not transmitted by physical devices."
kernel log output (truncated): WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140 ... Call Trace: <TASK> skb_checksum_help+0x12a/0x1f0 validate_xmit_skb+0x1a3/0x2d0 validate_xmit_skb_list+0x4f/0x80 sch_direct_xmit+0x1a2/0x380 __dev_xmit_skb+0x242/0x670 __dev_queue_xmit+0x3fc/0x7f0 ip6_finish_output2+0x25e/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel] ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre] dev_hard_start_xmit+0x63/0x1c0 __dev_queue_xmit+0x6d0/0x7f0 ip6_finish_output2+0x214/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 inet6_csk_xmit+0xeb/0x150 __tcp_transmit_skb+0x555/0xa80 tcp_write_xmit+0x32a/0xe90 tcp_sendmsg_locked+0x437/0x1110 tcp_sendmsg+0x2f/0x50 ... skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00 skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00 skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00 skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00 skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9 skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01 skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a(CVE-2025-39770)
In the Linux kernel, the following vulnerability has been resolved:
sctp: initialize more fields in sctp_v6_from_sk()
syzbot found that sin6_scope_id was not properly initialized, leading to undefined behavior.
Clear sin6_scope_id and sin6_flowinfo.
BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930(CVE-2025-39812)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix buffer free/clear order in deferred receive path
Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.
Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.(CVE-2025-39841)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm
When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen.
------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: <TASK> nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]---
To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning.
If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it.(CVE-2025-39894)
In the Linux kernel, the following vulnerability has been resolved:
net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer
Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkill_find_type() gets called with the possibly uninitialized "const char *type_name;" local variable.
On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id:
rfkill->type = (unsigned)id->driver_data;
and there is no "type" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash.
rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL.
Note likely sofar this has not been caught because:
- Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device
- The stack happened to contain NULL where type_name is stored(CVE-2025-39937)
In the Linux kernel, the following vulnerability has been resolved:
tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().
syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk in the TCP_ESTABLISHED state. [0]
syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:
- accept()
- connect(AF_UNSPEC)
- connect() to another destination
As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes it to TCP_CLOSE and makes connect() possible, which restarts timers.
Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.
Let's call reqsk_fastopen_remove() in tcp_disconnect().
[0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>(CVE-2025-39955)
In the Linux kernel, the following vulnerability has been resolved:
nexthop: Forbid FDB status change while nexthop is in a group
The kernel forbids the creation of non-FDB nexthop groups with FDB nexthops:
# ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops.
And vice versa:
# ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops.
However, as long as no routes are pointing to a non-FDB nexthop group, the kernel allows changing the type of a nexthop from FDB to non-FDB and vice versa:
# ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0
This configuration is invalid and can result in a NPD [1] since FDB nexthops are not associated with a nexthop device:
# ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1
Fix by preventing nexthop FDB status change while the nexthop is in a group:
# ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group.
[1] BUG: kernel NULL pointer dereference, address: 00000000000003c0 [...] Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:fib_lookup_good_nhc+0x1e/0x80 [...] Call Trace: <TASK> fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-39980)
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:
crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs
When the initialization of qm->debug.acc_diff_reg fails, the probe process does not exit. However, after qm->debug.qm_diff_regs is freed, it is not set to NULL. This can lead to a double free when the remove process attempts to free it again. Therefore, qm->debug.qm_diff_regs should be set to NULL after it is freed.(CVE-2025-40062)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Explicitly check accesses to bpf_sock_addr
Syzkaller found a kernel warning on the following sock_addr program:
0: r0 = 0
1: r2 = *(u32 *)(r1 +60)
2: exit
which triggers:
verifier bug: error during ctx access conversion (0)
This is happening because offset 60 in bpf_sock_addr corresponds to an implicit padding of 4 bytes, right after msg_src_ip4. Access to this padding isn't rejected in sock_addr_is_valid_access and it thus later fails to convert the access.
This patch fixes it by explicitly checking the various fields of bpf_sock_addr in sock_addr_is_valid_access.
I checked the other ctx structures and is_valid_access functions and didn't find any other similar cases. Other cases of (properly handled) padding are covered in new tests in a subsequent patch.(CVE-2025-40078)
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/qm - request reserved interrupt for virtual function
The device interrupt vector 3 is an error interrupt for physical function and a reserved interrupt for virtual function. However, the driver has not registered the reserved interrupt for virtual function. When allocating interrupts, the number of interrupts is allocated based on powers of two, which includes this interrupt. When the system enables GICv4 and the virtual function passthrough to the virtual machine, releasing the interrupt in the driver triggers a warning.
The WARNING report is: WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4
Therefore, register a reserved interrupt for VF and set the IRQF_NO_AUTOEN flag to avoid that warning.(CVE-2025-40136)
In the Linux kernel, the following vulnerability has been resolved:
sctp: avoid NULL dereference when chunk data buffer is missing
chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only.
chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.(CVE-2025-40240)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: remove never-working support for setting nsh fields
The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible.
There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it:
BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: <TASK> validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 _syssendmsg+0x36b/0x3a0 _sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump.
In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up.
Fixing all the issues is a complex task as it requires re-writing most of the validation code.
Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.(CVE-2025-40254)
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:
sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto
syzbot reported a possible shift-out-of-bounds [1]
Blamed commit added rto_alpha_max and rto_beta_max set to 1000.
It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta.
In order to prevent user regression, perform the test at run time.
Also add READ_ONCE() annotations as sysctl values can change under us.
[1]
UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 inline
In the Linux kernel, the following vulnerability has been resolved:
sctp: Prevent TOCTOU out-of-bounds write
For the following path not holding the sock lock,
sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()
make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use).(CVE-2025-40331)
In the Linux kernel, the following vulnerability has been resolved:
libceph: replace BUG_ON with bounds check for map->max_osd
OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd.
idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits
In the Linux kernel, the following vulnerability has been resolved:
libceph: prevent potential out-of-bounds writes in handle_auth_session_key()
The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets.
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:
Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b ("Bluetooth: convert conn hash to RCU") and not clear if it had purpose since then.
Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible.
Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup.
syzkaller has reported a crash that appears to be this issue:
[Task hdev->workqueue] [Task 2]
hci_disconnect_all_sync
l2cap_recv_acldata(hcon)
hci_conn_get(hcon)
hci_abort_conn_sync(hcon)
hci_dev_lock
hci_dev_lock
hci_conn_del(hcon)
v-------------------------------- hci_dev_unlock
hci_conn_put(hcon)
conn = hcon->l2cap_data (UAF)(CVE-2025-68304)
In the Linux kernel, the following vulnerability has been resolved:
ima: Handle error code returned by ima_filter_rule_match()
In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA.
This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match.
Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0
Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.(CVE-2025-68740)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix invalid prog->stats access when update_effective_progs fails
Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows:
__cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs / change to dummy_bpf_prog / array->items[index] = &dummy_bpf_prog.prog
---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) / invalid memory access / flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end---
static_branch_dec(&cgroup_bpf_enabled_key[atype])
The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access.
To fix it, skip updating stats when stats is NULL.(CVE-2025-68742)
In the Linux kernel, the following vulnerability has been resolved:
ethtool: Avoid overflowing userspace buffer on stats query
The ethtool -S command operates across three ioctl calls: ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and ETHTOOL_GSTATS for the values.
If the number of stats changes between these calls (e.g., due to device reconfiguration), userspace's buffer allocation will be incorrect, potentially leading to buffer overflow.
Drivers are generally expected to maintain stable stat counts, but some drivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making this scenario possible.
Some drivers try to handle this internally: - bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count. - micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.
However, both use stats.n_stats which is already assigned with the value returned from get_sset_count(), hence won't solve the issue described here.
Change ethtool_get_strings(), ethtool_get_stats(), ethtool_get_phy_stats() to not return anything in case of a mismatch between userspace's size and get_sset_size(), to prevent buffer overflow. The returned n_stats value will be equal to zero, to reflect that nothing has been returned.
This could result in one of two cases when using upstream ethtool, depending on when the size change is detected: 1. When detected in ethtool_get_strings(): # ethtool -S eth2 no stats available
- When detected in get stats, all stats will be reported as zero.
Both cases are presumably transient, and a subsequent ethtool call should succeed.
Other than the overflow avoidance, these two cases are very evident (no output/cleared stats), which is arguably better than presenting incorrect/shifted stats. I also considered returning an error instead of a "silent" response, but that seems more destructive towards userspace apps.
Notes: - This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.
-
RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.
-
Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.(CVE-2025-68795)
In the Linux kernel, the following vulnerability has been resolved:
ext4: xattr: fix null pointer deref in ext4_raw_inode()
If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all() lacks error checking, this will lead to a null pointer dereference in ext4_raw_inode(), called right after ext4_get_inode_loc().
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68820)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: using the num_tqps in the vf driver to apply for resources
Currently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqp is allocated using kinfo->num_tqps. However, kinfo->num_tqps is set to min(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smaller than hdev->num_tqps, which causes some hdev->htqp[i] to remain uninitialized in hclgevf_knic_setup().
Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps, ensuring that the lengths of hdev->htqp and kinfo->tqp are consistent and that all elements are properly initialized.(CVE-2025-71064)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset
qfq_class->leaf_qdisc->q.qlen > 0 does not imply that the class
itself is active.
Two qfq_class objects may point to the same leaf_qdisc. This happens when:
-
one QFQ qdisc is attached to the dev as the root qdisc, and
-
another QFQ qdisc is temporarily referenced (e.g., via qdisc_get() / qdisc_put()) and is pending to be destroyed, as in function tc_new_tfilter.
When packets are enqueued through the root QFQ qdisc, the shared leaf_qdisc->q.qlen increases. At the same time, the second QFQ qdisc triggers qdisc_put and qdisc_destroy: the qdisc enters qfq_reset() with its own q->q.qlen == 0, but its class's leaf qdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivate an inactive aggregate and trigger a null-deref in qfq_deactivate_agg:
[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 0.903571] #PF: supervisor write access in kernel mode [ 0.903860] #PF: error_code(0x0002) - not-present page [ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0 [ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI [ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE [ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2)) [ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0
Code starting with the faulting instruction
0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ... [ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246 [ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000 [ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000 [ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000 [ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880 [ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000 [ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0 [ 0.910247] PKRU: 55555554 [ 0.910391] Call Trace: [ 0.910527] <TASK> [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485) [ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036) [ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076) [ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447) [ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) [ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861) [ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550) [ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) [ 0.912296] ? __alloc_skb (net/core/skbuff.c:706) [ 0.912484] netlink_sendmsg (net/netlink/af ---truncated---(CVE-2026-22976)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix reference count leak in bpf_prog_test_run_xdp()
syzbot is reporting
unregister_netdevice: waiting for sit0 to become free. Usage count = 2
problem. A debug printk() patch found that a refcount is obtained at xdp_convert_md_to_buff() from bpf_prog_test_run_xdp().
According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdp_md context in BPF_PROG_TEST_RUN"), the refcount obtained by xdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md().
Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpf_prog_test_run_xdp()") forgot to call xdp_convert_buff_to_md().(CVE-2026-22994)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix a deadlock involving nfs_release_folio()
Wang Zhaolong reports a deadlock involving NFSv4.1 state recovery waiting on kthreadd, which is attempting to reclaim memory by calling nfs_release_folio(). The latter cannot make progress due to state recovery being needed.
It seems that the only safe thing to do here is to kick off a writeback of the folio, without waiting for completion, or else kicking off an asynchronous commit.(CVE-2026-23053)
In the Linux kernel, the following vulnerability has been resolved:
uacce: implement mremap in uacce_vm_ops to return -EPERM
The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users.
The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario:
An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).(CVE-2026-23056)
In the Linux kernel, the following vulnerability has been resolved:
uacce: ensure safe queue release with state management
Directly calling put_queue carries risks since it cannot
guarantee that resources of uacce_queue have been fully released
beforehand. So adding a stop_queue operation for the
UACCE_CMD_PUT_Q command and leaving the put_queue operation to
the final resource release ensures safety.
Queue states are defined as follows:
- UACCE_Q_ZOMBIE: Initial state
- UACCE_Q_INIT: After opening uacce
- UACCE_Q_STARTED: After start is issued via ioctl
When executing poweroff -f in virt while accelerator are still
working, uacce_fops_release and uacce_remove may execute
concurrently. This can cause uacce_put_queue within
uacce_fops_release to access a NULL ops pointer. Therefore, add
state checks to prevent accessing freed pointers.(CVE-2026-23063)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty.
Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}.
The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions.
Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.(CVE-2026-23253)
In the Linux kernel, the following vulnerability has been resolved:
regmap: maple: free entry on mas_store_gfp() failure
regcache_maple_write() allocates a new block ('entry') to merge adjacent ranges and then stores it with mas_store_gfp(). When mas_store_gfp() fails, the new 'entry' remains allocated and is never freed, leaking memory.
Free 'entry' on the failure path; on success continue freeing the replaced neighbor blocks ('lower', 'upper').(CVE-2026-23260)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix unprivileged local user can do privileged policy management
An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface.
This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation.
The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces.
Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check.(CVE-2026-23268)
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix __perf_event_overflow() vs perf_remove_from_context() race
Make sure that __perf_event_overflow() runs with IRQs disabled for all possible callchains. Specifically the software events can end up running it with only preemption disabled.
This opens up a race vs perf_event_exit_event() and friends that will go and free various things the overflow path expects to be present, like the BPF program.(CVE-2026-23271)
In the Linux kernel, the following vulnerability has been resolved:
macvlan: observe an RCU grace period in macvlan_common_newlink() error path
valis reported that a race condition still happens after my prior patch.
macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).
We must respect an RCU period, either in macvlan or the core networking stack.
After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was:
ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source
(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument
BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175
CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) ? tasklet_init (kernel/softirq.c:983) macvlan_handle_frame (drivers/net/macvlan.c:501)
Allocated by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) __kasan_kmalloc (mm/kasan/common.c:419) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657 mm/slub.c:7140) alloc_netdev_mqs (net/core/dev.c:12012) rtnl_create_link (net/core/rtnetlink.c:3648) rtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)
Freed by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kfree (mm/slub.c:6674 mm/slub.c:6882) rtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)(CVE-2026-23273)
In the Linux kernel, the following vulnerability has been resolved:
ext4: reject mount if bigalloc with s_first_data_block != 0
bigalloc with s_first_data_block != 0 is not supported, reject mounting it.(CVE-2026-31447)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: Check to ensure report responses match the request
It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.
Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Mitigate potential OOB by removing bogus memset()
The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.
The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.
Suggested-by Benjamin Tissoires <(CVE-2026-43048)
In the Linux kernel, there is a potential out-of-bounds access vulnerability in the ceph_handle_auth_reply() function of the libceph component. When processing messages of type CEPH_MSG_AUTH_REPLY, the value of the payload_len field is stored in a variable of type int. A value greater than INT_MAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-source-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"perf-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"python3-perf-6.6.0-145.0.12.138.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.12.138.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.12.138.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-source-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"perf-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"python3-perf-6.6.0-145.0.12.138.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.12.138.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-145.0.12.138.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"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:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: \u0026lt;TASK\u0026gt; kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI/MSI: Handle lack of irqdomain gracefully\n\nAlexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a\nRISCV platform which does not provide PCI/MSI support:\n\n WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32\n __pci_enable_msix_range+0x30c/0x596\n pci_msi_setup_msi_irqs+0x2c/0x32\n pci_alloc_irq_vectors_affinity+0xb8/0xe2\n\nRISCV uses hierarchical interrupt domains and correctly does not implement\nthe legacy fallback. The warning triggers from the legacy fallback stub.\n\nThat warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent\ndomain is associated with the device or not. There is a check for MSI-X,\nwhich has a legacy assumption. But that legacy fallback assumption is only\nvalid when legacy support is enabled, but otherwise the check should simply\nreturn -ENOTSUPP.\n\nLoongarch tripped over the same problem and blindly enabled legacy support\nwithout implementing the legacy fallbacks. There are weak implementations\nwhich return an error, so the problem was papered over.\n\nCorrect pci_msi_domain_supports() to evaluate the legacy mode and add\nthe missing supported check into the MSI enable path to complete it.(CVE-2024-56760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: fix nfs_release_folio() to not deadlock via kcompactd writeback\n\nAdd PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so\nnfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.\n\nOtherwise NFS can deadlock waiting for kcompactd enduced writeback which\nrecurses back to NFS (which triggers writeback to NFSD via NFS loopback\nmount on the same host, NFSD blocks waiting for XFS\u0026apos;s call to\n__filemap_get_folio):\n\n6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.\n\n{---\n[58] \u0026quot;kcompactd0\u0026quot;\n[\u0026lt;0\u0026gt;] folio_wait_bit+0xe8/0x200\n[\u0026lt;0\u0026gt;] folio_wait_writeback+0x2b/0x80\n[\u0026lt;0\u0026gt;] nfs_wb_folio+0x80/0x1b0 [nfs]\n[\u0026lt;0\u0026gt;] nfs_release_folio+0x68/0x130 [nfs]\n[\u0026lt;0\u0026gt;] split_huge_page_to_list_to_order+0x362/0x840\n[\u0026lt;0\u0026gt;] migrate_pages_batch+0x43d/0xb90\n[\u0026lt;0\u0026gt;] migrate_pages_sync+0x9a/0x240\n[\u0026lt;0\u0026gt;] migrate_pages+0x93c/0x9f0\n[\u0026lt;0\u0026gt;] compact_zone+0x8e2/0x1030\n[\u0026lt;0\u0026gt;] compact_node+0xdb/0x120\n[\u0026lt;0\u0026gt;] kcompactd+0x121/0x2e0\n[\u0026lt;0\u0026gt;] kthread+0xcf/0x100\n[\u0026lt;0\u0026gt;] ret_from_fork+0x31/0x40\n[\u0026lt;0\u0026gt;] ret_from_fork_asm+0x1a/0x30\n---}\n\n[(CVE-2025-21908)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio\n\nCommit b15c87263a69 (\u0026quot;hwpoison, memory_hotplug: allow hwpoisoned pages to\nbe offlined) add page poison checks in do_migrate_range in order to make\noffline hwpoisoned page possible by introducing isolate_lru_page and\ntry_to_unmap for hwpoisoned page. However folio lock must be held before\ncalling try_to_unmap. Add it to fix this problem.\n\nWarning will be produced if folio is not locked during unmap:\n\n ------------[ cut here ]------------\n kernel BUG at ./include/linux/swapops.h:400!\n Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n Modules linked in:\n CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41\n Tainted: [W]=WARN\n Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015\n pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : try_to_unmap_one+0xb08/0xd3c\n lr : try_to_unmap_one+0x3dc/0xd3c\n Call trace:\n try_to_unmap_one+0xb08/0xd3c (P)\n try_to_unmap_one+0x3dc/0xd3c (L)\n rmap_walk_anon+0xdc/0x1f8\n rmap_walk+0x3c/0x58\n try_to_unmap+0x88/0x90\n unmap_poisoned_folio+0x30/0xa8\n do_migrate_range+0x4a0/0x568\n offline_pages+0x5a4/0x670\n memory_block_action+0x17c/0x374\n memory_subsys_offline+0x3c/0x78\n device_offline+0xa4/0xd0\n state_store+0x8c/0xf0\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x44/0x54\n kernfs_fop_write_iter+0x118/0x1a8\n vfs_write+0x3a8/0x4bc\n ksys_write+0x6c/0xf8\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x44/0x100\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xd0\n el0t_64_sync_handler+0xc8/0xcc\n el0t_64_sync+0x198/0x19c\n Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000)\n ---[ end trace 0000000000000000 ]---(CVE-2025-21931)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Bridge, fix the crash caused by LAG state check\n\nWhen removing LAG device from bridge, NETDEV_CHANGEUPPER event is\ntriggered. Driver finds the lower devices (PFs) to flush all the\noffloaded entries. And mlx5_lag_is_shared_fdb is checked, it returns\nfalse if one of PF is unloaded. In such case,\nmlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead of\nthe alive PF, and the flush is skipped.\n\nBesides, the bridge fdb entry\u0026apos;s lastuse is updated in mlx5 bridge\nevent handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can be\nignored in this case because the upper interface for bond is deleted,\nand the entry will never be aged because lastuse is never updated.\n\nTo make things worse, as the entry is alive, mlx5 bridge workqueue\nkeeps sending that event, which is then handled by kernel bridge\nnotifier. It causes the following crash when accessing the passed bond\nnetdev which is already destroyed.\n\nTo fix this issue, remove such checks. LAG state is already checked in\ncommit 15f8f168952f (\u0026quot;net/mlx5: Bridge, verify LAG state when adding\nbond to bridge\u0026quot;), driver still need to skip offload if LAG becomes\ninvalid state after initialization.\n\n Oops: stack segment: 0000 [#1] SMP\n CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G OE 6.11.0_mlnx #1\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core]\n RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge]\n Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 \u0026lt;4c\u0026gt; 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7\n RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297\n RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff\n RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0\n RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8\n R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60\n R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? die+0x38/0x60\n ? do_trap+0x10b/0x120\n ? do_error_trap+0x64/0xa0\n ? exc_stack_segment+0x33/0x50\n ? asm_exc_stack_segment+0x22/0x30\n ? br_switchdev_event+0x2c/0x110 [bridge]\n ? sched_balance_newidle.isra.149+0x248/0x390\n notifier_call_chain+0x4b/0xa0\n atomic_notifier_call_chain+0x16/0x20\n mlx5_esw_bridge_update+0xec/0x170 [mlx5_core]\n mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core]\n process_scheduled_works+0x81/0x390\n worker_thread+0x106/0x250\n ? bh_worker+0x110/0x110\n kthread+0xb7/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 \u0026lt;/TASK\u0026gt;(CVE-2025-21970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: Prevent creation of classes with TC_H_ROOT\n\nThe function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination\ncondition when traversing up the qdisc tree to update parent backlog\ncounters. However, if a class is created with classid TC_H_ROOT, the\ntraversal terminates prematurely at this class instead of reaching the\nactual root qdisc, causing parent statistics to be incorrectly maintained.\nIn case of DRR, this could lead to a crash as reported by Mingi Cho.\n\nPrevent the creation of any Qdisc class with classid TC_H_ROOT\n(0xFFFFFFFF) across all qdisc types, as suggested by Jamal.(CVE-2025-21971)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: address a potential NULL pointer dereference in the GRED scheduler.\n\nIf kzalloc in gred_init returns a NULL pointer, the code follows the\nerror handling path, invoking gred_destroy. This, in turn, calls\ngred_offload, where memset could receive a NULL pointer as input,\npotentially leading to a kernel crash.\n\nWhen table-\u0026gt;opt is NULL in gred_init(), gred_change_table_def()\nis not called yet, so it is not necessary to call -\u0026gt;ndo_setup_tc()\nin gred_offload().(CVE-2025-21980)\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\nnet: switchdev: Convert blocking notification chain to a raw one\n\nA blocking notification chain uses a read-write semaphore to protect the\nintegrity of the chain. The semaphore is acquired for writing when\nadding / removing notifiers to / from the chain and acquired for reading\nwhen traversing the chain and informing notifiers about an event.\n\nIn case of the blocking switchdev notification chain, recursive\nnotifications are possible which leads to the semaphore being acquired\ntwice for reading and to lockdep warnings being generated [1].\n\nSpecifically, this can happen when the bridge driver processes a\nSWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications\nabout deferred events when calling switchdev_deferred_process().\n\nFix this by converting the notification chain to a raw notification\nchain in a similar fashion to the netdev notification chain. Protect\nthe chain using the RTNL mutex by acquiring it when modifying the chain.\nEvents are always informed under the RTNL mutex, but add an assertion in\ncall_switchdev_blocking_notifiers() to make sure this is not violated in\nthe future.\n\nMaintain the \u0026quot;blocking\u0026quot; prefix as events are always emitted from process\ncontext and listeners are allowed to block.\n\n[1]:\nWARNING: possible recursive locking detected\n6.14.0-rc4-custom-g079270089484 #1 Not tainted\n--------------------------------------------\nip/52731 is trying to acquire lock:\nffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nbut task is already holding lock:\nffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nother info that might help us debug this:\nPossible unsafe locking scenario:\nCPU0\n----\nlock((switchdev_blocking_notif_chain).rwsem);\nlock((switchdev_blocking_notif_chain).rwsem);\n\n*** DEADLOCK ***\nMay be due to missing lock nesting notation\n3 locks held by ip/52731:\n #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0\n #1: ffffffff8731f628 (\u0026amp;net-\u0026gt;rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0\n #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nstack backtrace:\n...\n? __pfx_down_read+0x10/0x10\n? __pfx_mark_lock+0x10/0x10\n? __pfx_switchdev_port_attr_set_deferred+0x10/0x10\nblocking_notifier_call_chain+0x58/0xa0\nswitchdev_port_attr_notify.constprop.0+0xb3/0x1b0\n? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10\n? mark_held_locks+0x94/0xe0\n? switchdev_deferred_process+0x11a/0x340\nswitchdev_port_attr_set_deferred+0x27/0xd0\nswitchdev_deferred_process+0x164/0x340\nbr_switchdev_port_unoffload+0xc8/0x100 [bridge]\nbr_switchdev_blocking_event+0x29f/0x580 [bridge]\nnotifier_call_chain+0xa2/0x440\nblocking_notifier_call_chain+0x6e/0xa0\nswitchdev_bridge_port_unoffload+0xde/0x1a0\n...(CVE-2025-21986)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sched: Fix fence reference count leak\n\nThe last_scheduled fence leaks when an entity is being killed and adding\nthe cleanup callback fails.\n\nDecrement the reference count of prev when dma_fence_add_callback()\nfails, ensuring proper balance.\n\n[phasta: add git tag info for stable kernel](CVE-2025-21995)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naccel/qaic: Fix integer overflow in qaic_validate_req()\n\nThese are u64 variables that come from the user via\nqaic_attach_slice_bo_ioctl(). Use check_add_overflow() to ensure that\nthe math doesn\u0026apos;t have an integer wrapping bug.(CVE-2025-22001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: dummy: force synchronous probing\n\nSometimes I get a NULL pointer dereference at boot time in kobject_get()\nwith the following call stack:\n\nanatop_regulator_probe()\n devm_regulator_register()\n regulator_register()\n regulator_resolve_supply()\n kobject_get()\n\nBy placing some extra BUG_ON() statements I could verify that this is\nraised because probing of the \u0026apos;dummy\u0026apos; regulator driver is not completed\n(\u0026apos;dummy_regulator_rdev\u0026apos; is still NULL).\n\nIn the JTAG debugger I can see that dummy_regulator_probe() and\nanatop_regulator_probe() can be run by different kernel threads\n(kworker/u4:*). I haven\u0026apos;t further investigated whether this can be\nchanged or if there are other possibilities to force synchronization\nbetween these two probe routines. On the other hand I don\u0026apos;t expect much\nboot time penalty by probing the \u0026apos;dummy\u0026apos; regulator synchronously.(CVE-2025-22009)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix a leak in spufs_create_context()\n\nLeak fixes back in 2008 missed one case - if we are trying to set affinity\nand spufs_mkdir() fails, we need to drop the reference to neighbor.(CVE-2025-22071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert \u0026quot;smb: client: fix TCP timers deadlock after rmmod\u0026quot;\n\nThis reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.\n\nCommit e9f2517a3e18 (\u0026quot;smb: client: fix TCP timers deadlock after\nrmmod\u0026quot;) is intended to fix a null-ptr-deref in LOCKDEP, which is\nmentioned as CVE-2024-54680, but is actually did not fix anything;\nThe issue can be reproduced on top of it. [0]\n\nAlso, it reverted the change by commit ef7134c7fc48 (\u0026quot;smb: client:\nFix use-after-free of network namespace.\u0026quot;) and introduced a real\nissue by reviving the kernel TCP socket.\n\nWhen a reconnect happens for a CIFS connection, the socket state\ntransitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()\nin tcp_close() stops all timers for the socket.\n\nIf an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1\nforever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.\n\nUsually, FIN can be retransmitted by the peer, but if the peer aborts\nthe connection, the issue comes into reality.\n\nI warned about this privately by pointing out the exact report [1],\nbut the bogus fix was finally merged.\n\nSo, we should not stop the timers to finally kill the connection on\nour side in that case, meaning we must not use a kernel socket for\nTCP whose sk-\u0026gt;sk_net_refcnt is 0.\n\nThe kernel socket does not have a reference to its netns to make it\npossible to tear down netns without cleaning up every resource in it.\n\nFor example, tunnel devices use a UDP socket internally, but we can\ndestroy netns without removing such devices and let it complete\nduring exit. Otherwise, netns would be leaked when the last application\ndied.\n\nHowever, this is problematic for TCP sockets because TCP has timers to\nclose the connection gracefully even after the socket is close()d. The\nlifetime of the socket and its netns is different from the lifetime of\nthe underlying connection.\n\nIf the socket user does not maintain the netns lifetime, the timer could\nbe fired after the socket is close()d and its netns is freed up, resulting\nin use-after-free.\n\nActually, we have seen so many similar issues and converted such sockets\nto have a reference to netns.\n\nThat\u0026apos;s why I converted the CIFS client socket to have a reference to\nnetns (sk-\u0026gt;sk_net_refcnt == 1), which is somehow mentioned as out-of-scope\nof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right\nfix**.\n\nRegarding the LOCKDEP issue, we can prevent the module unload by\nbumping the module refcount when switching the LOCKDDEP key in\nsock_lock_init_class_and_name(). [2]\n\nFor a while, let\u0026apos;s revert the bogus fix.\n\nNote that now we can use sk_net_refcnt_upgrade() for the socket\nconversion, but I\u0026apos;ll do so later separately to make backport easy.(CVE-2025-22077)\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\nmedia: venus: hfi_parser: add check to avoid out of bound access\n\nThere is a possibility that init_codecs is invoked multiple times during\nmanipulated payload from video firmware. In such case, if codecs_count\ncan get incremented to value more than MAX_CODEC_NUM, there can be OOB\naccess. Reset the count so that it always starts from beginning.(CVE-2025-23157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add sanity check for agwidth in dbMount\n\nThe width in dmapctl of the AG is zero, it trigger a divide error when\ncalculating the control page level in dbAllocAG.\n\nTo avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group\n\nCurrently, mtk_iommu calls during probe iommu_device_register before\nthe hw_list from driver data is initialized. Since iommu probing issue\nfix, it leads to NULL pointer dereference in mtk_iommu_device_group when\nhw_list is accessed with list_first_entry (not null safe).\n\nSo, change the call order to ensure iommu_device_register is called\nafter the driver data are initialized.(CVE-2025-37748)\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-37768)\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\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-37771)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix dangling pointer in krb_authenticate\n\nkrb_authenticate frees sess-\u0026gt;user and does not set the pointer\nto NULL. It calls ksmbd_krb5_authenticate to reinitialise\nsess-\u0026gt;user but that function may return without doing so. If\nthat happens then smb2_sess_setup, which calls krb_authenticate,\nwill be accessing free\u0026apos;d memory when it later uses sess-\u0026gt;user.(CVE-2025-37778)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\navs_component_probe() does not check for this case, which results in a\nNULL pointer dereference.(CVE-2025-37793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsound/virtio: Fix cancel_sync warnings on uninitialized work_structs\n\nBetty reported hitting the following warning:\n\n[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182\n...\n[ 8.713282][ T221] Call trace:\n[ 8.713365][ T221] __flush_work+0x8d0/0x914\n[ 8.713468][ T221] __cancel_work_sync+0xac/0xfc\n[ 8.713570][ T221] cancel_work_sync+0x24/0x34\n[ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]\n[ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]\n[ 8.714035][ T221] virtio_dev_probe+0x28c/0x390\n[ 8.714139][ T221] really_probe+0x1bc/0x4c8\n...\n\nIt seems we\u0026apos;re hitting the error path in virtsnd_probe(), which\ntriggers a virtsnd_remove() which iterates over the substreams\ncalling cancel_work_sync() on the elapsed_period work_struct.\n\nLooking at the code, from earlier in:\nvirtsnd_probe()-\u0026gt;virtsnd_build_devs()-\u0026gt;virtsnd_pcm_parse_cfg()\n\nWe set snd-\u0026gt;nsubstreams, allocate the snd-\u0026gt;substreams, and if\nwe then hit an error on the info allocation or something in\nvirtsnd_ctl_query_info() fails, we will exit without having\ninitialized the elapsed_period work_struct.\n\nWhen that error path unwinds we then call virtsnd_remove()\nwhich as long as the substreams array is allocated, will iterate\nthrough calling cancel_work_sync() on the uninitialized work\nstruct hitting this warning.\n\nTakashi Iwai suggested this fix, which initializes the substreams\nstructure right after allocation, so that if we hit the error\npaths we avoid trying to cleanup uninitialized data.\n\nNote: I have not yet managed to reproduce the issue myself, so\nthis patch has had limited testing.\n\nFeedback or thoughts would be appreciated!(CVE-2025-37805)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration\n\nResolve kernel panic while accessing IRQ handler associated with the\ngenerated IRQ. This is done by acquiring the spinlock and storing the\ncurrent interrupt state before handling the interrupt request using\ngeneric_handle_irq.\n\nA previous fix patch was submitted where \u0026apos;generic_handle_irq\u0026apos; was\nreplaced with \u0026apos;handle_nested_irq\u0026apos;. However, this change also causes\nthe kernel panic where after determining which GPIO triggered the\ninterrupt and attempting to call handle_nested_irq with the mapped\nIRQ number, leads to a failure in locating the registered handler.(CVE-2025-37815)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy-\u0026gt;cpus mask. apple_soc_cpufreq_get_rate() does not check\nfor this case, which results in a NULL pointer dereference.(CVE-2025-37831)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: avoid NULL pointer dereference in dbg call\n\ncifs_server_dbg() implies server to be non-NULL so\nmove call under condition to avoid NULL pointer dereference.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37844)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: debugfs hang_hws skip GPU with MES\n\ndebugfs hang_hws is used by GPU reset test with HWS, for MES this crash\nthe kernel with NULL pointer access because dqm-\u0026gt;packet_mgr is not setup\nfor MES path.\n\nSkip GPU with MES for now, MES hang_hws debugfs interface will be\nsupported later.(CVE-2025-37853)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()\n\nThe variable d-\u0026gt;name, returned by devm_kasprintf(), could be NULL.\nA pointer check is added to prevent potential NULL pointer dereference.\nThis is similar to the fix in commit 3027e7b15b02\n(\u0026quot;ice: Fix some null pointer dereference issues in ice_ptp.c\u0026quot;).\n\nThis issue is found by our static analysis tool(CVE-2025-37881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Consistently treat platform_max as control value\n\nThis reverts commit 9bdd10d57a88 (\u0026quot;ASoC: ops: Shift tested values in\nsnd_soc_put_volsw() by +min\u0026quot;), and makes some additional related\nupdates.\n\nThere are two ways the platform_max could be interpreted; the maximum\nregister value, or the maximum value the control can be set to. The\npatch moved from treating the value as a control value to a register\none. When the patch was applied it was technically correct as\nsnd_soc_limit_volume() also used the register interpretation. However,\neven then most of the other usages treated platform_max as a\ncontrol value, and snd_soc_limit_volume() has since been updated to\nalso do so in commit fb9ad24485087 (\u0026quot;ASoC: ops: add correct range\ncheck for limiting volume\u0026quot;). That patch however, missed updating\nsnd_soc_put_volsw() back to the control interpretation, and fixing\nsnd_soc_info_volsw_range(). The control interpretation makes more\nsense as limiting is typically done from the machine driver, so it is\nappropriate to use the customer facing representation rather than the\ninternal codec representation. Update all the code to consistently use\nthis interpretation of platform_max.\n\nFinally, also add some comments to the soc_mixer_control struct to\nhopefully avoid further patches switching between the two approaches.(CVE-2025-37889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scmi: Balance device refcount when destroying devices\n\nUsing device_find_child() to lookup the proper SCMI device to destroy\ncauses an unbalance in device refcount, since device_find_child() calls an\nimplicit get_device(): this, in turns, inhibits the call of the provided\nrelease methods upon devices destruction.\n\nAs a consequence, one of the structures that is not freed properly upon\ndestruction is the internal struct device_private dev-\u0026gt;p populated by the\ndrivers subsystem core.\n\nKMemleak detects this situation since loading/unloding some SCMI driver\ncauses related devices to be created/destroyed without calling any\ndevice_release method.\n\nunreferenced object 0xffff00000f583800 (size 512):\n comm \u0026quot;insmod\u0026quot;, pid 227, jiffies 4294912190\n hex dump (first 32 bytes):\n 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........\n ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6......\n backtrace (crc 114e2eed):\n kmemleak_alloc+0xbc/0xd8\n __kmalloc_cache_noprof+0x2dc/0x398\n device_add+0x954/0x12d0\n device_register+0x28/0x40\n __scmi_device_create.part.0+0x1bc/0x380\n scmi_device_create+0x2d0/0x390\n scmi_create_protocol_devices+0x74/0xf8\n scmi_device_request_notifier+0x1f8/0x2a8\n notifier_call_chain+0x110/0x3b0\n blocking_notifier_call_chain+0x70/0xb0\n scmi_driver_register+0x350/0x7f0\n 0xffff80000a3b3038\n do_one_initcall+0x12c/0x730\n do_init_module+0x1dc/0x640\n load_module+0x4b20/0x5b70\n init_module_from_file+0xec/0x158\n\n$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0\ndevice_add+0x954/0x12d0:\nkmalloc_noprof at include/linux/slab.h:901\n(inlined by) kzalloc_noprof at include/linux/slab.h:1037\n(inlined by) device_private_init at drivers/base/core.c:3510\n(inlined by) device_add at drivers/base/core.c:3561\n\nBalance device refcount by issuing a put_device() on devices found via\ndevice_find_child().(CVE-2025-37905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()\n\nA NULL pointer dereference can occur in skb_dequeue() when processing a\nQCA firmware crash dump on WCN7851 (0489:e0f3).\n\n[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)\n\n[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]\n[ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80\n\nThe issue stems from handle_dump_pkt_qca() returning 0 even when a dump\npacket is successfully processed. This is because it incorrectly\nforwards the return value of hci_devcd_init() (which returns 0 on\nsuccess). As a result, the caller (btusb_recv_acl_qca() or\nbtusb_recv_evt_qca()) assumes the packet was not handled and passes it\nto hci_recv_frame(), leading to premature kfree() of the skb.\n\nLater, hci_devcd_rx() attempts to dequeue the same skb from the dump\nqueue, resulting in a NULL pointer dereference.\n\nFix this by:\n1. Making handle_dump_pkt_qca() return 0 on success and negative errno\n on failure, consistent with kernel conventions.\n2. Splitting dump packet detection into separate functions for ACL\n and event packets for better structure and readability.\n\nThis ensures dump packets are properly identified and consumed, avoiding\ndouble handling and preventing NULL pointer access.(CVE-2025-37918)\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\nusb: typec: ucsi: displayport: Fix deadlock\n\nThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock\nfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connector\nmutex is only locked if a connection is established and the partner pointer\nis valid. This resolves a deadlock scenario where\nucsi_displayport_remove_partner holds con-\u0026gt;mutex waiting for\ndp_altmode_work to complete while dp_altmode_work attempts to acquire it.(CVE-2025-37967)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Refactor remove call with idxd_cleanup() helper\n\nThe idxd_cleanup() helper cleans up perfmon, interrupts, internals and\nso on. Refactor remove call with the idxd_cleanup() helper to avoid code\nduplication. Note, this also fixes the missing put_device() for idxd\ngroups, enginces and wqs.(CVE-2025-38014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Annotate FDB data races\n\nThe \u0026apos;used\u0026apos; and \u0026apos;updated\u0026apos; fields in the FDB entry structure can be\naccessed concurrently by multiple threads, leading to reports such as\n[1]. Can be reproduced using [2].\n\nSuppress these reports by annotating these accesses using\nREAD_ONCE() / WRITE_ONCE().\n\n[1]\nBUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit\n\nwrite to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0:\n vxlan_xmit+0xb29/0x2380\n dev_hard_start_xmit+0x84/0x2f0\n __dev_queue_xmit+0x45a/0x1650\n packet_xmit+0x100/0x150\n packet_sendmsg+0x2114/0x2ac0\n __sys_sendto+0x318/0x330\n __x64_sys_sendto+0x76/0x90\n x64_sys_call+0x14e8/0x1c00\n do_syscall_64+0x9e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2:\n vxlan_xmit+0xadf/0x2380\n dev_hard_start_xmit+0x84/0x2f0\n __dev_queue_xmit+0x45a/0x1650\n packet_xmit+0x100/0x150\n packet_sendmsg+0x2114/0x2ac0\n __sys_sendto+0x318/0x330\n __x64_sys_sendto+0x76/0x90\n x64_sys_call+0x14e8/0x1c00\n do_syscall_64+0x9e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nvalue changed: 0x00000000fffbac6e -\u0026gt; 0x00000000fffbac6f\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\n\n[2]\n #!/bin/bash\n\n set +H\n echo whitelist \u0026gt; /sys/kernel/debug/kcsan\n echo !vxlan_xmit \u0026gt; /sys/kernel/debug/kcsan\n\n ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1\n taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q \u0026amp;\n taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q \u0026amp;(CVE-2025-38037)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_ffa: Set dma_mask for ffa devices\n\nSet dma_mask for FFA devices, otherwise DMA allocation using the device pointer\nlead to following warning:\n\nWARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124(CVE-2025-38043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix use-after-free in cifs_fill_dirent\n\nThere is a race condition in the readdir concurrency process, which may\naccess the rsp buffer after it has been released, triggering the\nfollowing KASAN warning.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]\n Read of size 4 at addr ffff8880099b819c by task a.out/342975\n\n CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x53/0x70\n print_report+0xce/0x640\n kasan_report+0xb8/0xf0\n cifs_fill_dirent+0xb03/0xb60 [cifs]\n cifs_readdir+0x12cb/0x3190 [cifs]\n iterate_dir+0x1a1/0x520\n __x64_sys_getdents+0x134/0x220\n do_syscall_64+0x4b/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f996f64b9f9\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89\n f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01\n f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8\n RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e\n RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88\n R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 408:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n __kasan_slab_alloc+0x6e/0x70\n kmem_cache_alloc_noprof+0x117/0x3d0\n mempool_alloc_noprof+0xf2/0x2c0\n cifs_buf_get+0x36/0x80 [cifs]\n allocate_buffers+0x1d2/0x330 [cifs]\n cifs_demultiplex_thread+0x22b/0x2690 [cifs]\n kthread+0x394/0x720\n ret_from_fork+0x34/0x70\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 342979:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x37/0x50\n kmem_cache_free+0x2b8/0x500\n cifs_buf_release+0x3c/0x70 [cifs]\n cifs_readdir+0x1c97/0x3190 [cifs]\n iterate_dir+0x1a1/0x520\n __x64_sys_getdents64+0x134/0x220\n do_syscall_64+0x4b/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n The buggy address belongs to the object at ffff8880099b8000\n which belongs to the cache cifs_request of size 16588\n The buggy address is located 412 bytes inside of\n freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8\n head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n anon flags: 0x80000000000040(head|node=0|zone=1)\n page_type: f5(slab)\n raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff\n head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n \u0026gt;ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ^\n ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ==================================================================\n\nPOC is available in the link [1].\n\nThe problem triggering process is as follows:\n\nProcess 1 Process 2\n-----------------------------------\n---truncated---(CVE-2025-38051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio: break and reset virtio devices on device_shutdown()\n\nHongyu reported a hang on kexec in a VM. QEMU reported invalid memory\naccesses during the hang.\n\n\tInvalid read at addr 0x102877002, size 2, region \u0026apos;(null)\u0026apos;, reason: rejected\n\tInvalid write at addr 0x102877A44, size 2, region \u0026apos;(null)\u0026apos;, reason: rejected\n\t...\n\nIt was traced down to virtio-console. Kexec works fine if virtio-console\nis not in use.\n\nThe issue is that virtio-console continues to write to the MMIO even after\nunderlying virtio-pci device is reset.\n\nAdditionally, Eric noticed that IOMMUs are reset before devices, if\ndevices are not reset on shutdown they continue to poke at guest memory\nand get errors from the IOMMU. Some devices get wedged then.\n\nThe problem can be solved by breaking all virtio devices on virtio\nbus shutdown, then resetting them.(CVE-2025-38064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: CPPC: Fix NULL pointer dereference when nosmp is used\n\nWith nosmp in cmdline, other CPUs are not brought up, leaving\ntheir cpc_desc_ptr NULL. CPU0\u0026apos;s iteration via for_each_possible_cpu()\ndereferences these NULL pointers, causing panic.\n\nPanic backtrace:\n\n[ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8\n...\n[ 0.403255] [\u0026lt;ffffffff809a5818\u0026gt;] cppc_allow_fast_switch+0x6a/0xd4\n...\nKernel panic - not syncing: Attempted to kill init!\n\n[ rjw: New subject ](CVE-2025-38113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngve: add missing NULL check for gve_alloc_pending_packet() in TX DQO\n\ngve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()\ndid not check for this case before dereferencing the returned pointer.\n\nAdd a missing NULL check to prevent a potential NULL pointer\ndereference when allocation fails.\n\nThis improves robustness in low-memory scenarios.(CVE-2025-38122)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: t7xx: Fix napi rx poll issue\n\nWhen driver handles the napi rx polling requests, the netdev might\nhave been released by the dellink logic triggered by the disconnect\noperation on user plane. However, in the logic of processing skb in\npolling, an invalid netdev is still being used, which causes a panic.\n\nBUG: kernel NULL pointer dereference, address: 00000000000000f1\nOops: 0000 [#1] PREEMPT SMP NOPTI\nRIP: 0010:dev_gro_receive+0x3a/0x620\n[...]\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n ? __die_body+0x68/0xb0\n ? page_fault_oops+0x379/0x3e0\n ? exc_page_fault+0x4f/0xa0\n ? asm_exc_page_fault+0x22/0x30\n ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)]\n ? dev_gro_receive+0x3a/0x620\n napi_gro_receive+0xad/0x170\n t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)]\n t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)]\n net_rx_action+0x103/0x470\n irq_exit_rcu+0x13a/0x310\n sysvec_apic_timer_interrupt+0x56/0x90\n \u0026lt;/IRQ\u0026gt;(CVE-2025-38123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: prevent deactivate active config while enabling the config\n\nWhile enable active config via cscfg_csdev_enable_active_config(),\nactive config could be deactivated via configfs\u0026apos; sysfs interface.\nThis could make UAF issue in below scenario:\n\nCPU0 CPU1\n(sysfs enable) load module\n cscfg_load_config_sets()\n activate config. // sysfs\n (sys_active_cnt == 1)\n...\ncscfg_csdev_enable_active_config()\nlock(csdev-\u0026gt;cscfg_csdev_lock)\n// here load config activate by CPU1\nunlock(csdev-\u0026gt;cscfg_csdev_lock)\n\n deactivate config // sysfs\n (sys_activec_cnt == 0)\n cscfg_unload_config_sets()\n unload module\n\n// access to config_desc which freed\n// while unloading module.\ncscfg_csdev_enable_config\n\nTo address this, use cscfg_config_desc\u0026apos;s active_cnt as a reference count\n which will be holded when\n - activate the config.\n - enable the activated config.\nand put the module reference when config_active_cnt == 0.(CVE-2025-38131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: mscc: Fix memory leak when using one step timestamping\n\nFix memory leak when running one-step timestamping. When running\none-step sync timestamping, the HW is configured to insert the TX time\ninto the frame, so there is no reason to keep the skb anymore. As in\nthis case the HW will never generate an interrupt to say that the frame\nwas timestamped, then the frame will never released.\nFix this by freeing the frame in case of one-step timestamping.(CVE-2025-38148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix error flow upon firmware failure for RQ destruction\n\nUpon RQ destruction if the firmware command fails which is the\nlast resource to be destroyed some SW resources were already cleaned\nregardless of the failure.\n\nNow properly rollback the object to its original state upon such failure.\n\nIn order to avoid a use-after free in case someone tries to destroy the\nobject again, which results in the following kernel trace:\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148\nModules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)\nCPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1\nTainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\nHardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : refcount_warn_saturate+0xf4/0x148\nlr : refcount_warn_saturate+0xf4/0x148\nsp : ffff80008b81b7e0\nx29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001\nx26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00\nx23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000\nx20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006\nx17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f\nx14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78\nx11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90\nx8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff\nx5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600\nCall trace:\n refcount_warn_saturate+0xf4/0x148\n mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib]\n mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib]\n mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib]\n ib_destroy_wq_user+0x30/0xc0 [ib_core]\n uverbs_free_wq+0x28/0x58 [ib_uverbs]\n destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs]\n uverbs_destroy_uobject+0x48/0x240 [ib_uverbs]\n __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs]\n uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs]\n ib_uverbs_close+0x2c/0x100 [ib_uverbs]\n __fput+0xd8/0x2f0\n __fput_sync+0x50/0x70\n __arm64_sys_close+0x40/0x90\n invoke_syscall.constprop.0+0x74/0xd0\n do_el0_svc+0x48/0xe8\n el0_svc+0x44/0x1d0\n el0t_64_sync_handler+0x120/0x130\n el0t_64_sync+0x1a4/0x1a8(CVE-2025-38161)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get()\n\nBefore calling lan743x_ptp_io_event_clock_get(), the \u0026apos;channel\u0026apos; value\nis checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8).\nThis seems correct and aligns with the PTP interrupt status register\n(PTP_INT_STS) specifications.\n\nHowever, lan743x_ptp_io_event_clock_get() writes to ptp-\u0026gt;extts[] with\nonly LAN743X_PTP_N_EXTTS(4) elements, using channel as an index:\n\n lan743x_ptp_io_event_clock_get(..., u8 channel,...)\n {\n ...\n /* Update Local timestamp */\n extts = \u0026amp;ptp-\u0026gt;extts[channel];\n extts-\u0026gt;ts.tv_sec = sec;\n ...\n }\n\nTo avoid an out-of-bounds write and utilize all the supported GPIO\ninputs, set LAN743X_PTP_N_EXTTS to 8.\n\nDetected using the static analysis tool - Svace.(CVE-2025-38183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: reject invalid perturb period\n\nGerrard Tai reported that SFQ perturb_period has no range check yet,\nand this can be used to trigger a race condition fixed in a separate patch.\n\nWe want to make sure ctl-\u0026gt;perturb_period * HZ will not overflow\nand is positive.\n\n\ntc qd add dev lo root sfq perturb -10 # negative value : error\nError: sch_sfq: invalid perturb period.\n\ntc qd add dev lo root sfq perturb 1000000000 # too big : error\nError: sch_sfq: invalid perturb period.\n\ntc qd add dev lo root sfq perturb 2000000 # acceptable value\ntc -s -d qd sh dev lo\nqdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec\n Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)\n backlog 0b 0p requeues 0(CVE-2025-38193)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: check that raw node were preallocated before writing summary\n\nSyzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault\ninjection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn\u0026apos;t\ncheck return value of jffs2_prealloc_raw_node_refs and simply lets any\nerror propagate into jffs2_sum_write_data, which eventually calls\njffs2_link_node_ref in order to link the summary to an expectedly allocated\nnode.\n\nkernel BUG at fs/jffs2/nodelist.c:592!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]\n jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874\n jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388\n jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197\n jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362\n jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301\n generic_perform_write+0x314/0x5d0 mm/filemap.c:3856\n __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973\n generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005\n call_write_iter include/linux/fs.h:2265 [inline]\n do_iter_readv_writev+0x20f/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+0x10c/0x170 fs/splice.c:950\n splice_direct_to_actor+0x337/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\n\nFix this issue by checking return value of jffs2_prealloc_raw_node_refs\nbefore calling jffs2_sum_write_data.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem, swap: fix softlockup with mTHP swapin\n\nFollowing softlockup can be easily reproduced on my test machine with:\n\necho always \u0026gt; /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled\nswapon /dev/zram0 # zram0 is a 48G swap device\nmkdir -p /sys/fs/cgroup/memory/test\necho 1G \u0026gt; /sys/fs/cgroup/test/memory.max\necho $BASHPID \u0026gt; /sys/fs/cgroup/test/cgroup.procs\nwhile true; do\n dd if=/dev/zero of=/tmp/test.img bs=1M count=5120\n cat /tmp/test.img \u0026gt; /dev/null\n rm /tmp/test.img\ndone\n\nThen after a while:\nwatchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]\nModules linked in: zram virtiofs\nCPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)\u00b7\nTainted: [L]=SOFTLOCKUP\nHardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015\nRIP: 0010:mpol_shared_policy_lookup+0xd/0x70\nCode: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 \u0026lt;48\u0026gt; 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8\nRSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202\nRAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001\nRDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518\nRBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001\nR13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000\nFS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n shmem_alloc_folio+0x31/0xc0\n shmem_swapin_folio+0x309/0xcf0\n ? filemap_get_entry+0x117/0x1e0\n ? xas_load+0xd/0xb0\n ? filemap_get_entry+0x101/0x1e0\n shmem_get_folio_gfp+0x2ed/0x5b0\n shmem_file_read_iter+0x7f/0x2e0\n vfs_read+0x252/0x330\n ksys_read+0x68/0xf0\n do_syscall_64+0x4c/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f03f9a46991\nCode: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991\nRDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003\nRBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\n\nThe reason is simple, readahead brought some order 0 folio in swap cache,\nand the swapin mTHP folio being allocated is in conflict with it, so\nswapcache_prepare fails and causes shmem_swap_alloc_folio to return\n-EEXIST, and shmem simply retries again and again causing this loop.\n\nFix it by applying a similar fix for anon mTHP swapin.\n\nThe performance change is very slight, time of swapin 10g zero folios\nwith shmem (test for 12 times):\nBefore: 2.47s\nAfter: 2.48s\n\n[(CVE-2025-38241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()\n\nWhile testing null_blk with configfs, echo 0 \u0026gt; poll_queues will trigger\nfollowing panic:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000010\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\nRIP: 0010:__bitmap_or+0x48/0x70\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __group_cpus_evenly+0x822/0x8c0\n group_cpus_evenly+0x2d9/0x490\n blk_mq_map_queues+0x1e/0x110\n null_map_queues+0xc9/0x170 [null_blk]\n blk_mq_update_queue_map+0xdb/0x160\n blk_mq_update_nr_hw_queues+0x22b/0x560\n nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]\n nullb_device_poll_queues_store+0xa4/0x130 [null_blk]\n configfs_write_iter+0x109/0x1d0\n vfs_write+0x26e/0x6f0\n ksys_write+0x79/0x180\n __x64_sys_write+0x1d/0x30\n x64_sys_call+0x45c4/0x45f0\n do_syscall_64+0xa5/0x240\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nRoot cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from\nkcalloc(), and later ZERO_SIZE_PTR will be deferenced.\n\nFix the problem by checking numgrps first in group_cpus_evenly(), and\nreturn NULL directly if numgrps is zero.\n\n[(CVE-2025-38255)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix NULL pointer deference on eir_get_service_data\n\nThe len parameter is considered optional so it can be NULL so it cannot\nbe used for skipping to next entry of EIR_SERVICE_DATA.(CVE-2025-38304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: avs: Verify content returned by parse_int_array()\n\nThe first element of the returned array stores its length. If it is 0,\nany manipulation beyond the element at index 0 ends with null-ptr-deref.(CVE-2025-38307)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: Log an error when close_all_cached_dirs fails\n\nUnder low-memory conditions, close_all_cached_dirs() can\u0026apos;t move the\ndentries to a separate list to dput() them once the locks are dropped.\nThis will result in a \u0026quot;Dentry still in use\u0026quot; error, so add an error\nmessage that makes it clear this is what happened:\n\n[ 495.281119] CIFS: VFS: \\\\otters.example.com\\share Out of memory while dropping dentries\n[ 495.281595] ------------[ cut here ]------------\n[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs]\n[ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0\n\nAlso, bail out of looping through all tcons as soon as a single\nallocation fails, since we\u0026apos;re already in trouble, and kmalloc() attempts\nfor subseqeuent tcons are likely to fail just like the first one did.(CVE-2025-38321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: fix acpi parse and parseext cache leaks\n\nACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5\n\nI\u0026apos;m Seunghun Han, and I work for National Security Research Institute of\nSouth Korea.\n\nI have been doing a research on ACPI and found an ACPI cache leak in ACPI\nearly abort cases.\n\nBoot log of ACPI cache leak is as follows:\n[ 0.352414] ACPI: Added _OSI(Module Device)\n[ 0.353182] ACPI: Added _OSI(Processor Device)\n[ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)\n[ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)\n[ 0.356028] ACPI: Unable to start the ACPI Interpreter\n[ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)\n[ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects\n[ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W\n4.12.0-rc4-next-20170608+ #10\n[ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS\nvirtual_box 12/01/2006\n[ 0.361873] Call Trace:\n[ 0.362243] ? dump_stack+0x5c/0x81\n[ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0\n[ 0.362944] ? acpi_sleep_proc_init+0x27/0x27\n[ 0.363296] ? acpi_os_delete_cache+0xa/0x10\n[ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b\n[ 0.364000] ? acpi_terminate+0xa/0x14\n[ 0.364000] ? acpi_init+0x2af/0x34f\n[ 0.364000] ? __class_create+0x4c/0x80\n[ 0.364000] ? video_setup+0x7f/0x7f\n[ 0.364000] ? acpi_sleep_proc_init+0x27/0x27\n[ 0.364000] ? do_one_initcall+0x4e/0x1a0\n[ 0.364000] ? kernel_init_freeable+0x189/0x20a\n[ 0.364000] ? rest_init+0xc0/0xc0\n[ 0.364000] ? kernel_init+0xa/0x100\n[ 0.364000] ? ret_from_fork+0x25/0x30\n\nI analyzed this memory leak in detail. I found that \u201cAcpi-State\u201d cache and\n\u201cAcpi-Parse\u201d cache were merged because the size of cache objects was same\nslab cache size.\n\nI finally found \u201cAcpi-Parse\u201d cache and \u201cAcpi-parse_ext\u201d cache were leaked\nusing SLAB_NEVER_MERGE flag in kmem_cache_create() function.\n\nReal ACPI cache leak point is as follows:\n[ 0.360101] ACPI: Added _OSI(Module Device)\n[ 0.360101] ACPI: Added _OSI(Processor Device)\n[ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)\n[ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)\n[ 0.364016] ACPI: Unable to start the ACPI Interpreter\n[ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)\n[ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects\n[ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W\n4.12.0-rc4-next-20170608+ #8\n[ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS\nvirtual_box 12/01/2006\n[ 0.372000] Call Trace:\n[ 0.372000] ? dump_stack+0x5c/0x81\n[ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0\n[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27\n[ 0.372000] ? acpi_os_delete_cache+0xa/0x10\n[ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b\n[ 0.372000] ? acpi_terminate+0xa/0x14\n[ 0.372000] ? acpi_init+0x2af/0x34f\n[ 0.372000] ? __class_create+0x4c/0x80\n[ 0.372000] ? video_setup+0x7f/0x7f\n[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27\n[ 0.372000] ? do_one_initcall+0x4e/0x1a0\n[ 0.372000] ? kernel_init_freeable+0x189/0x20a\n[ 0.372000] ? rest_init+0xc0/0xc0\n[ 0.372000] ? kernel_init+0xa/0x100\n[ 0.372000] ? ret_from_fork+0x25/0x30\n[ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects\n[ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W\n4.12.0-rc4-next-20170608+ #8\n[ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS\nvirtual_box 12/01/2006\n[ 0.392000] Call Trace:\n[ 0.392000] ? dump_stack+0x5c/0x81\n[ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0\n[ 0.392000] ? acpi_sleep_proc_init+0x27/0x27\n[ 0.392000] ? acpi_os_delete_cache+0xa/0x10\n[ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b\n[ 0.392000] ? acpi_terminate+0xa/0x14\n[ 0.392000] ? acpi_init+0x2af/0x3\n---truncated---(CVE-2025-38344)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmaple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()\n\nTemporarily clear the preallocation flag when explicitly requesting\nallocations. Pre-existing allocations are already counted against the\nrequest through mas_node_count_gfp(), but the allocations will not happen\nif the MA_STATE_PREALLOC flag is set. This flag is meant to avoid\nre-allocating in bulk allocation mode, and to detect issues with\npreallocation calculations.\n\nThe MA_STATE_PREALLOC flag should also always be set on zero allocations\nso that detection of underflow allocations will print a WARN_ON() during\nconsumption.\n\nUser visible effect of this flaw is a WARN_ON() followed by a null pointer\ndereference when subsequent requests for larger number of nodes is\nignored, such as the vma merge retry in mmap_region() caused by drivers\naltering the vma flags (which happens in v6.6, at least)(CVE-2025-38364)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Fix transport_* TOCTOU\n\nTransport assignment may race with module unload. Protect new_transport\nfrom becoming a stale pointer.\n\nThis also takes care of an insecure call in vsock_use_local_transport();\nadd a lockdep assert.\n\nBUG: unable to handle page fault for address: fffffbfff8056000\nOops: Oops: 0000 [#1] SMP KASAN\nRIP: 0010:vsock_assign_transport+0x366/0x600\nCall Trace:\n vsock_connect+0x59c/0xc40\n __sys_connect+0xe8/0x100\n __x64_sys_connect+0x6e/0xc0\n do_syscall_64+0x92/0x1c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38461)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Fix transport_{g2h,h2g} TOCTOU\n\nvsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.\ntransport_{g2h,h2g} may become NULL after the NULL check.\n\nIntroduce vsock_transport_local_cid() to protect from a potential\nnull-ptr-deref.\n\nKASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\nRIP: 0010:vsock_find_cid+0x47/0x90\nCall Trace:\n __vsock_bind+0x4b2/0x720\n vsock_bind+0x90/0xe0\n __sys_bind+0x14d/0x1e0\n __x64_sys_bind+0x6e/0xc0\n do_syscall_64+0x92/0x1c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nKASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\nRIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0\nCall Trace:\n __x64_sys_ioctl+0x12d/0x190\n do_syscall_64+0x92/0x1c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38462)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in crypt_message when using async crypto\n\nThe CVE-2024-50047 fix removed asynchronous crypto handling from\ncrypt_message(), assuming all crypto operations are synchronous.\nHowever, when hardware crypto accelerators are used, this can cause\nuse-after-free crashes:\n\n crypt_message()\n // Allocate the creq buffer containing the req\n creq = smb2_get_aead_req(..., \u0026amp;req);\n\n // Async encryption returns -EINPROGRESS immediately\n rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);\n\n // Free creq while async operation is still in progress\n kvfree_sensitive(creq, ...);\n\nHardware crypto modules often implement async AEAD operations for\nperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,\nthe operation completes asynchronously. Without crypto_wait_req(),\nthe function immediately frees the request buffer, leading to crashes\nwhen the driver later accesses the freed memory.\n\nThis results in a use-after-free condition when the hardware crypto\ndriver later accesses the freed request structure, leading to kernel\ncrashes with NULL pointer dereferences.\n\nThe issue occurs because crypto_alloc_aead() with mask=0 doesn\u0026apos;t\nguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in\nthe mask, async implementations can be selected.\n\nFix by restoring the async crypto handling:\n- DECLARE_CRYPTO_WAIT(wait) for completion tracking\n- aead_request_set_callback() for async completion notification\n- crypto_wait_req() to wait for operation completion\n\nThis ensures the request buffer isn\u0026apos;t freed until the crypto operation\ncompletes, whether synchronous or asynchronous, while preserving the\nCVE-2024-50047 fix.(CVE-2025-38488)\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\nmptcp: plug races between subflow fail and subflow creation\n\nWe have races similar to the one addressed by the previous patch between\nsubflow failing and additional subflow creation. They are just harder to\ntrigger.\n\nThe solution is similar. Use a separate flag to track the condition\n\u0026apos;socket state prevent any additional subflow creation\u0026apos; protected by the\nfallback lock.\n\nThe socket fallback makes such flag true, and also receiving or sending\nan MP_FAIL option.\n\nThe field \u0026apos;allow_infinite_fallback\u0026apos; is now always touched under the\nrelevant lock, we can drop the ONCE annotation on write.(CVE-2025-38552)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: use aead_request_free to match aead_request_alloc\n\nUse aead_request_free() instead of kfree() to properly free memory\nallocated by aead_request_alloc(). This ensures sensitive crypto data\nis zeroed before being freed.(CVE-2025-38575)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Check governor before using governor-\u0026gt;name\n\nCommit 96ffcdf239de (\u0026quot;PM / devfreq: Remove redundant governor_name from\nstruct devfreq\u0026quot;) removes governor_name and uses governor-\u0026gt;name to replace\nit. But devfreq-\u0026gt;governor may be NULL and directly using\ndevfreq-\u0026gt;governor-\u0026gt;name may cause null pointer exception. Move the check of\ngovernor to before using governor-\u0026gt;name.(CVE-2025-38609)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: fix refcount leak on table dump\n\nThere is a reference count leak in ctnetlink_dump_table():\n if (res \u0026lt; 0) {\n nf_conntrack_get(\u0026amp;ct-\u0026gt;ct_general); // HERE\n cb-\u0026gt;args[1] = (unsigned long)ct;\n ...\n\nWhile its very unlikely, its possible that ct == last.\nIf this happens, then the refcount of ct was already incremented.\nThis 2nd increment is never undone.\n\nThis prevents the conntrack object from being released, which in turn\nkeeps prevents cnet-\u0026gt;count from dropping back to 0.\n\nThis will then block the netns dismantle (or conntrack rmmod) as\nnf_conntrack_cleanup_net_list() will wait forever.\n\nThis can be reproduced by running conntrack_resize.sh selftest in a loop.\nIt takes ~20 minutes for me on a preemptible kernel on average before\nI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.\n\nOne fix would to change this to:\n if (res \u0026lt; 0) {\n\t\tif (ct != last)\n\t nf_conntrack_get(\u0026amp;ct-\u0026gt;ct_general);\n\nBut this reference counting isn\u0026apos;t needed in the first place.\nWe can just store a cookie value instead.\n\nA followup patch will do the same for ctnetlink_exp_dump_table,\nit looks to me as if this has the same problem and like\nctnetlink_dump_table, we only need a \u0026apos;skip hint\u0026apos;, not the actual\nobject so we can apply the same cookie strategy there as well.(CVE-2025-38721)\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\ntls: fix handling of zero-length records on the rx_list\n\nEach recvmsg() call must process either\n - only contiguous DATA records (any number of them)\n - one non-DATA record\n\nIf the next record has different type than what has already been\nprocessed we break out of the main processing loop. If the record\nhas already been decrypted (which may be the case for TLS 1.3 where\nwe don\u0026apos;t know type until decryption) we queue the pending record\nto the rx_list. Next recvmsg() will pick it up from there.\n\nQueuing the skb to rx_list after zero-copy decrypt is not possible,\nsince in that case we decrypted directly to the user space buffer,\nand we don\u0026apos;t have an skb to queue (darg.skb points to the ciphertext\nskb for access to metadata like length).\n\nOnly data records are allowed zero-copy, and we break the processing\nloop after each non-data record. So we should never zero-copy and\nthen find out that the record type has changed. The corner case\nwe missed is when the initial record comes from rx_list, and it\u0026apos;s\nzero length.(CVE-2025-39682)\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\nclk: samsung: Fix UBSAN panic in samsung_clk_init()\n\nWith UBSAN_ARRAY_BOUNDS=y, I\u0026apos;m hitting the below panic due to\ndereferencing `ctx-\u0026gt;clk_data.hws` before setting\n`ctx-\u0026gt;clk_data.num = nr_clks`. Move that up to fix the crash.\n\n UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP\n \u0026lt;snip\u0026gt;\n Call trace:\n samsung_clk_init+0x110/0x124 (P)\n samsung_clk_init+0x48/0x124 (L)\n samsung_cmu_register_one+0x3c/0xa0\n exynos_arm64_register_cmu+0x54/0x64\n __gs101_cmu_top_of_clk_init_declare+0x28/0x60\n ...(CVE-2025-39728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: Prevent file descriptor table allocations exceeding INT_MAX\n\nWhen sysctl_nr_open is set to a very high value (for example, 1073741816\nas set by systemd), processes attempting to use file descriptors near\nthe limit can trigger massive memory allocation attempts that exceed\nINT_MAX, resulting in a WARNING in mm/slub.c:\n\n WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288\n\nThis happens because kvmalloc_array() and kvmalloc() check if the\nrequested size exceeds INT_MAX and emit a warning when the allocation is\nnot flagged with __GFP_NOWARN.\n\nSpecifically, when nr_open is set to 1073741816 (0x3ffffff8) and a\nprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:\n- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes\n- Multiple bitmaps: ~400MB\n- Total allocation size: \u0026gt; 8GB (exceeding INT_MAX = 2,147,483,647)\n\nReproducer:\n1. Set /proc/sys/fs/nr_open to 1073741816:\n # echo 1073741816 \u0026gt; /proc/sys/fs/nr_open\n\n2. Run a program that uses a high file descriptor:\n #include \u0026lt;unistd.h\u0026gt;\n #include \u0026lt;sys/resource.h\u0026gt;\n\n int main() {\n struct rlimit rlim = {1073741824, 1073741824};\n setrlimit(RLIMIT_NOFILE, \u0026amp;rlim);\n dup2(2, 1073741880); // Triggers the warning\n return 0;\n }\n\n3. Observe WARNING in dmesg at mm/slub.c:5027\n\nsystemd commit a8b627a introduced automatic bumping of fs.nr_open to the\nmaximum possible value. The rationale was that systems with memory\ncontrol groups (memcg) no longer need separate file descriptor limits\nsince memory is properly accounted. However, this change overlooked\nthat:\n\n1. The kernel\u0026apos;s allocation functions still enforce INT_MAX as a maximum\n size regardless of memcg accounting\n2. Programs and tests that legitimately test file descriptor limits can\n inadvertently trigger massive allocations\n3. The resulting allocations (\u0026gt;8GB) are impractical and will always fail\n\nsystemd\u0026apos;s algorithm starts with INT_MAX and keeps halving the value\nuntil the kernel accepts it. On most systems, this results in nr_open\nbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of file\ndescriptors.\n\nWhile processes rarely use file descriptors near this limit in normal\noperation, certain selftests (like\ntools/testing/selftests/core/unshare_test.c) and programs that test file\ndescriptor limits can trigger this issue.\n\nFix this by adding a check in alloc_fdtable() to ensure the requested\nallocation size does not exceed INT_MAX. This causes the operation to\nfail with -EMFILE instead of triggering a kernel warning and avoids the\nimpractical \u0026gt;8GB memory allocation request.(CVE-2025-39756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM\n\nWhen performing Generic Segmentation Offload (GSO) on an IPv6 packet that\ncontains extension headers, the kernel incorrectly requests checksum offload\nif the egress device only advertises NETIF_F_IPV6_CSUM feature, which has\na strict contract: it supports checksum offload only for plain TCP or UDP\nover IPv6 and explicitly does not support packets with extension headers.\nThe current GSO logic violates this contract by failing to disable the feature\nfor packets with extension headers, such as those used in GREoIPv6 tunnels.\n\nThis violation results in the device being asked to perform an operation\nit cannot support, leading to a `skb_warn_bad_offload` warning and a collapse\nof network throughput. While device TSO/USO is correctly bypassed in favor\nof software GSO for these packets, the GSO stack must be explicitly told not\nto request checksum offload.\n\nMask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4\nin gso_features_check if the IPv6 header contains extension headers to compute\nchecksum in software.\n\nThe exception is a BIG TCP extension, which, as stated in commit\n68e068cabd2c6c53 (\u0026quot;net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets\u0026quot;):\n\u0026quot;The feature is only enabled on devices that support BIG TCP TSO.\nThe header is only present for PF_PACKET taps like tcpdump,\nand not transmitted by physical devices.\u0026quot;\n\nkernel log output (truncated):\nWARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_checksum_help+0x12a/0x1f0\n validate_xmit_skb+0x1a3/0x2d0\n validate_xmit_skb_list+0x4f/0x80\n sch_direct_xmit+0x1a2/0x380\n __dev_xmit_skb+0x242/0x670\n __dev_queue_xmit+0x3fc/0x7f0\n ip6_finish_output2+0x25e/0x5d0\n ip6_finish_output+0x1fc/0x3f0\n ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel]\n ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre]\n dev_hard_start_xmit+0x63/0x1c0\n __dev_queue_xmit+0x6d0/0x7f0\n ip6_finish_output2+0x214/0x5d0\n ip6_finish_output+0x1fc/0x3f0\n ip6_xmit+0x2ca/0x6f0\n ip6_finish_output+0x1fc/0x3f0\n ip6_xmit+0x2ca/0x6f0\n inet6_csk_xmit+0xeb/0x150\n __tcp_transmit_skb+0x555/0xa80\n tcp_write_xmit+0x32a/0xe90\n tcp_sendmsg_locked+0x437/0x1110\n tcp_sendmsg+0x2f/0x50\n...\nskb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e\nskb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00\nskb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00\nskb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00\nskb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00\nskb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00\nskb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9\nskb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01\nskb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a(CVE-2025-39770)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: initialize more fields in sctp_v6_from_sk()\n\nsyzbot found that sin6_scope_id was not properly initialized,\nleading to undefined behavior.\n\nClear sin6_scope_id and sin6_flowinfo.\n\nBUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649\n __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649\n sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983\n sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390\n sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452\n sctp_get_port net/sctp/socket.c:8523 [inline]\n sctp_listen_start net/sctp/socket.c:8567 [inline]\n sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636\n __sys_listen_socket net/socket.c:1912 [inline]\n __sys_listen net/socket.c:1927 [inline]\n __do_sys_listen net/socket.c:1932 [inline]\n __se_sys_listen net/socket.c:1930 [inline]\n __x64_sys_listen+0x343/0x4c0 net/socket.c:1930\n x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nLocal variable addr.i.i created at:\n sctp_get_port net/sctp/socket.c:8515 [inline]\n sctp_listen_start net/sctp/socket.c:8567 [inline]\n sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636\n __sys_listen_socket net/socket.c:1912 [inline]\n __sys_listen net/socket.c:1927 [inline]\n __do_sys_listen net/socket.c:1932 [inline]\n __se_sys_listen net/socket.c:1930 [inline]\n __x64_sys_listen+0x343/0x4c0 net/socket.c:1930(CVE-2025-39812)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix buffer free/clear order in deferred receive path\n\nFix a use-after-free window by correcting the buffer release sequence in\nthe deferred receive path. The code freed the RQ buffer first and only\nthen cleared the context pointer under the lock. Concurrent paths (e.g.,\nABTS and the repost path) also inspect and release the same pointer under\nthe lock, so the old order could lead to double-free/UAF.\n\nNote that the repost path already uses the correct pattern: detach the\npointer under the lock, then free it after dropping the lock. The\ndeferred path should do the same.(CVE-2025-39841)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm\n\nWhen send a broadcast packet to a tap device, which was added to a bridge,\nbr_nf_local_in() is called to confirm the conntrack. If another conntrack\nwith the same hash value is added to the hash table, which can be\ntriggered by a normal packet to a non-bridge device, the below warning\nmay happen.\n\n ------------[ cut here ]------------\n WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200\n CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary)\n RIP: 0010:br_nf_local_in+0x168/0x200\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nf_hook_slow+0x3e/0xf0\n br_pass_frame_up+0x103/0x180\n br_handle_frame_finish+0x2de/0x5b0\n br_nf_hook_thresh+0xc0/0x120\n br_nf_pre_routing_finish+0x168/0x3a0\n br_nf_pre_routing+0x237/0x5e0\n br_handle_frame+0x1ec/0x3c0\n __netif_receive_skb_core+0x225/0x1210\n __netif_receive_skb_one_core+0x37/0xa0\n netif_receive_skb+0x36/0x160\n tun_get_user+0xa54/0x10c0\n tun_chr_write_iter+0x65/0xb0\n vfs_write+0x305/0x410\n ksys_write+0x60/0xd0\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nTo solve the hash conflict, nf_ct_resolve_clash() try to merge the\nconntracks, and update skb-\u0026gt;_nfct. However, br_nf_local_in() still use the\nold ct from local variable \u0026apos;nfct\u0026apos; after confirm(), which leads to this\nwarning.\n\nIf confirm() does not insert the conntrack entry and return NF_DROP, the\nwarning may also occur. There is no need to reserve the WARN_ON_ONCE, just\nremove it.(CVE-2025-39894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer\n\nSince commit 7d5e9737efda (\u0026quot;net: rfkill: gpio: get the name and type from\ndevice property\u0026quot;) rfkill_find_type() gets called with the possibly\nuninitialized \u0026quot;const char *type_name;\u0026quot; local variable.\n\nOn x86 systems when rfkill-gpio binds to a \u0026quot;BCM4752\u0026quot; or \u0026quot;LNV4752\u0026quot;\nacpi_device, the rfkill-\u0026gt;type is set based on the ACPI acpi_device_id:\n\n rfkill-\u0026gt;type = (unsigned)id-\u0026gt;driver_data;\n\nand there is no \u0026quot;type\u0026quot; property so device_property_read_string() will fail\nand leave type_name uninitialized, leading to a potential crash.\n\nrfkill_find_type() does accept a NULL pointer, fix the potential crash\nby initializing type_name to NULL.\n\nNote likely sofar this has not been caught because:\n\n1. Not many x86 machines actually have a \u0026quot;BCM4752\u0026quot;/\u0026quot;LNV4752\u0026quot; acpi_device\n2. The stack happened to contain NULL where type_name is stored(CVE-2025-39937)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Clear tcp_sk(sk)-\u0026gt;fastopen_rsk in tcp_disconnect().\n\nsyzbot reported the splat below where a socket had tcp_sk(sk)-\u0026gt;fastopen_rsk\nin the TCP_ESTABLISHED state. [0]\n\nsyzbot reused the server-side TCP Fast Open socket as a new client before\nthe TFO socket completes 3WHS:\n\n 1. accept()\n 2. connect(AF_UNSPEC)\n 3. connect() to another destination\n\nAs of accept(), sk-\u0026gt;sk_state is TCP_SYN_RECV, and tcp_disconnect() changes\nit to TCP_CLOSE and makes connect() possible, which restarts timers.\n\nSince tcp_disconnect() forgot to clear tcp_sk(sk)-\u0026gt;fastopen_rsk, the\nretransmit timer triggered the warning and the intended packet was not\nretransmitted.\n\nLet\u0026apos;s call reqsk_fastopen_remove() in tcp_disconnect().\n\n[0]:\nWARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))\nModules linked in:\nCPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))\nCode: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 \u0026lt;0f\u0026gt; 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e\nRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293\nRAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017\nRDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400\nRBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8\nR10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540\nR13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0\nFS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n tcp_write_timer (net/ipv4/tcp_timer.c:738)\n call_timer_fn (kernel/time/timer.c:1747)\n __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)\n timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)\n tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)\n __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))\n tmigr_handle_remote (kernel/time/timer_migration.c:1096)\n handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)\n irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))\n \u0026lt;/IRQ\u0026gt;(CVE-2025-39955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnexthop: Forbid FDB status change while nexthop is in a group\n\nThe kernel forbids the creation of non-FDB nexthop groups with FDB\nnexthops:\n\n # ip nexthop add id 1 via 192.0.2.1 fdb\n # ip nexthop add id 2 group 1\n Error: Non FDB nexthop group cannot have fdb nexthops.\n\nAnd vice versa:\n\n # ip nexthop add id 3 via 192.0.2.2 dev dummy1\n # ip nexthop add id 4 group 3 fdb\n Error: FDB nexthop group can only have fdb nexthops.\n\nHowever, as long as no routes are pointing to a non-FDB nexthop group,\nthe kernel allows changing the type of a nexthop from FDB to non-FDB and\nvice versa:\n\n # ip nexthop add id 5 via 192.0.2.2 dev dummy1\n # ip nexthop add id 6 group 5\n # ip nexthop replace id 5 via 192.0.2.2 fdb\n # echo $?\n 0\n\nThis configuration is invalid and can result in a NPD [1] since FDB\nnexthops are not associated with a nexthop device:\n\n # ip route add 198.51.100.1/32 nhid 6\n # ping 198.51.100.1\n\nFix by preventing nexthop FDB status change while the nexthop is in a\ngroup:\n\n # ip nexthop add id 7 via 192.0.2.2 dev dummy1\n # ip nexthop add id 8 group 7\n # ip nexthop replace id 7 via 192.0.2.2 fdb\n Error: Cannot change nexthop FDB status while in a group.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 00000000000003c0\n[...]\nOops: Oops: 0000 [#1] SMP\nCPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:fib_lookup_good_nhc+0x1e/0x80\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n fib_table_lookup+0x541/0x650\n ip_route_output_key_hash_rcu+0x2ea/0x970\n ip_route_output_key_hash+0x55/0x80\n __ip4_datagram_connect+0x250/0x330\n udp_connect+0x2b/0x60\n __sys_connect+0x9c/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0xa4/0x2a0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-39980)\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\ncrypto: hisilicon/qm - set NULL to qm-\u0026gt;debug.qm_diff_regs\n\nWhen the initialization of qm-\u0026gt;debug.acc_diff_reg fails,\nthe probe process does not exit. However, after qm-\u0026gt;debug.qm_diff_regs is\nfreed, it is not set to NULL. This can lead to a double free when the\nremove process attempts to free it again. Therefore, qm-\u0026gt;debug.qm_diff_regs\nshould be set to NULL after it is freed.(CVE-2025-40062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Explicitly check accesses to bpf_sock_addr\n\nSyzkaller found a kernel warning on the following sock_addr program:\n\n 0: r0 = 0\n 1: r2 = *(u32 *)(r1 +60)\n 2: exit\n\nwhich triggers:\n\n verifier bug: error during ctx access conversion (0)\n\nThis is happening because offset 60 in bpf_sock_addr corresponds to an\nimplicit padding of 4 bytes, right after msg_src_ip4. Access to this\npadding isn\u0026apos;t rejected in sock_addr_is_valid_access and it thus later\nfails to convert the access.\n\nThis patch fixes it by explicitly checking the various fields of\nbpf_sock_addr in sock_addr_is_valid_access.\n\nI checked the other ctx structures and is_valid_access functions and\ndidn\u0026apos;t find any other similar cases. Other cases of (properly handled)\npadding are covered in new tests in a subsequent patch.(CVE-2025-40078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/qm - request reserved interrupt for virtual function\n\nThe device interrupt vector 3 is an error interrupt for\nphysical function and a reserved interrupt for virtual function.\nHowever, the driver has not registered the reserved interrupt for\nvirtual function. When allocating interrupts, the number of interrupts\nis allocated based on powers of two, which includes this interrupt.\nWhen the system enables GICv4 and the virtual function passthrough\nto the virtual machine, releasing the interrupt in the driver\ntriggers a warning.\n\nThe WARNING report is:\nWARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4\n\nTherefore, register a reserved interrupt for VF and set the\nIRQF_NO_AUTOEN flag to avoid that warning.(CVE-2025-40136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: avoid NULL dereference when chunk data buffer is missing\n\nchunk-\u0026gt;skb pointer is dereferenced in the if-block where it\u0026apos;s supposed\nto be NULL only.\n\nchunk-\u0026gt;skb can only be NULL if chunk-\u0026gt;head_skb is not. Check for frag_list\ninstead and do it just before replacing chunk-\u0026gt;skb. We\u0026apos;re sure that\notherwise chunk-\u0026gt;skb is non-NULL because of outer if() condition.(CVE-2025-40240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: remove never-working support for setting nsh fields\n\nThe validation of the set(nsh(...)) action is completely wrong.\nIt runs through the nsh_key_put_from_nlattr() function that is the\nsame function that validates NSH keys for the flow match and the\npush_nsh() action. However, the set(nsh(...)) has a very different\nmemory layout. Nested attributes in there are doubled in size in\ncase of the masked set(). That makes proper validation impossible.\n\nThere is also confusion in the code between the \u0026apos;masked\u0026apos; flag, that\nsays that the nested attributes are doubled in size containing both\nthe value and the mask, and the \u0026apos;is_mask\u0026apos; that says that the value\nwe\u0026apos;re parsing is the mask. This is causing kernel crash on trying to\nwrite into mask part of the match with SW_FLOW_KEY_PUT() during\nvalidation, while validate_nsh() doesn\u0026apos;t allocate any memory for it:\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 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0\n Oops: Oops: 0000 [#1] SMP NOPTI\n CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary)\n RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n validate_nsh+0x60/0x90 [openvswitch]\n validate_set.constprop.0+0x270/0x3c0 [openvswitch]\n __ovs_nla_copy_actions+0x477/0x860 [openvswitch]\n ovs_nla_copy_actions+0x8d/0x100 [openvswitch]\n ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch]\n genl_family_rcv_msg_doit+0xdb/0x130\n genl_family_rcv_msg+0x14b/0x220\n genl_rcv_msg+0x47/0xa0\n netlink_rcv_skb+0x53/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x280/0x3b0\n netlink_sendmsg+0x1f7/0x430\n ____sys_sendmsg+0x36b/0x3a0\n ___sys_sendmsg+0x87/0xd0\n __sys_sendmsg+0x6d/0xd0\n do_syscall_64+0x7b/0x2c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe third issue with this process is that while trying to convert\nthe non-masked set into masked one, validate_set() copies and doubles\nthe size of the OVS_KEY_ATTR_NSH as if it didn\u0026apos;t have any nested\nattributes. It should be copying each nested attribute and doubling\nthem in size independently. And the process must be properly reversed\nduring the conversion back from masked to a non-masked variant during\nthe flow dump.\n\nIn the end, the only two outcomes of trying to use this action are\neither validation failure or a kernel crash. And if somehow someone\nmanages to install a flow with such an action, it will most definitely\nnot do what it is supposed to, since all the keys and the masks are\nmixed up.\n\nFixing all the issues is a complex task as it requires re-writing\nmost of the validation code.\n\nGiven that and the fact that this functionality never worked since\nintroduction, let\u0026apos;s just remove it altogether. It\u0026apos;s better to\nre-introduce it later with a proper implementation instead of trying\nto fix it in stable releases.(CVE-2025-40254)\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\nsctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto\n\nsyzbot reported a possible shift-out-of-bounds [1]\n\nBlamed commit added rto_alpha_max and rto_beta_max set to 1000.\n\nIt is unclear if some sctp users are setting very large rto_alpha\nand/or rto_beta.\n\nIn order to prevent user regression, perform the test at run time.\n\nAlso add READ_ONCE() annotations as sysctl values can change under us.\n\n[1]\n\nUBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41\nshift exponent 64 is too large for 32-bit type \u0026apos;unsigned int\u0026apos;\nCPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:233 [inline]\n __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494\n sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509\n sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502\n sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338\n sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline]\n sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline](CVE-2025-40281)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: Prevent TOCTOU out-of-bounds write\n\nFor the following path not holding the sock lock,\n\n sctp_diag_dump() -\u0026gt; sctp_for_each_endpoint() -\u0026gt; sctp_ep_dump()\n\nmake sure not to exceed bounds in case the address list has grown\nbetween buffer allocation (time-of-check) and write (time-of-use).(CVE-2025-40331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: replace BUG_ON with bounds check for map-\u0026gt;max_osd\n\nOSD indexes come from untrusted network packets. Boundary checks are\nadded to validate these against map-\u0026gt;max_osd.\n\n[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic\n edits ](CVE-2025-68283)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: prevent potential out-of-bounds writes in handle_auth_session_key()\n\nThe len field originates from untrusted network packets. Boundary\nchecks have been added to prevent potential out-of-bounds writes when\ndecrypting the connection secret or processing service tickets.\n\n[ idryomov: changelog ](CVE-2025-68284)\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\nBluetooth: hci_core: lookup hci_conn on RX path on protocol side\n\nThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn\u0026apos;t\nensure hci_conn* is not concurrently modified/deleted. This locking\nappears to be leftover from before conn_hash started using RCU\ncommit bf4c63252490b (\u0026quot;Bluetooth: convert conn hash to RCU\u0026quot;)\nand not clear if it had purpose since then.\n\nCurrently, there are code paths that delete hci_conn* from elsewhere\nthan the ordered hdev-\u0026gt;workqueue where the RX work runs in. E.g.\ncommit 5af1f84ed13a (\u0026quot;Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\u0026quot;)\nintroduced some of these, and there probably were a few others before\nit. It\u0026apos;s better to do the locking so that even if these run\nconcurrently no UAF is possible.\n\nMove the lookup of hci_conn and associated socket-specific conn to\nprotocol recv handlers, and do them within a single critical section\nto cover hci_conn* usage and lookup.\n\nsyzkaller has reported a crash that appears to be this issue:\n\n [Task hdev-\u0026gt;workqueue] [Task 2]\n hci_disconnect_all_sync\n l2cap_recv_acldata(hcon)\n hci_conn_get(hcon)\n hci_abort_conn_sync(hcon)\n hci_dev_lock\n hci_dev_lock\n hci_conn_del(hcon)\n v-------------------------------- hci_dev_unlock\n hci_conn_put(hcon)\n conn = hcon-\u0026gt;l2cap_data (UAF)(CVE-2025-68304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nima: Handle error code returned by ima_filter_rule_match()\n\nIn ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to\nthe rule being NULL, the function incorrectly skips the \u0026apos;if (!rc)\u0026apos; check\nand sets \u0026apos;result = true\u0026apos;. The LSM rule is considered a match, causing\nextra files to be measured by IMA.\n\nThis issue can be reproduced in the following scenario:\nAfter unloading the SELinux policy module via \u0026apos;semodule -d\u0026apos;, if an IMA\nmeasurement is triggered before ima_lsm_rules is updated,\nin ima_match_rules(), the first call to ima_filter_rule_match() returns\n-ESTALE. This causes the code to enter the \u0026apos;if (rc == -ESTALE \u0026amp;\u0026amp;\n!rule_reinitialized)\u0026apos; block, perform ima_lsm_copy_rule() and retry. In\nima_lsm_copy_rule(), since the SELinux module has been removed, the rule\nbecomes NULL, and the second call to ima_filter_rule_match() returns\n-ENOENT. This bypasses the \u0026apos;if (!rc)\u0026apos; check and results in a false match.\n\nCall trace:\n selinux_audit_rule_match+0x310/0x3b8\n security_audit_rule_match+0x60/0xa0\n ima_match_rules+0x2e4/0x4a0\n ima_match_policy+0x9c/0x1e8\n ima_get_action+0x48/0x60\n process_measurement+0xf8/0xa98\n ima_bprm_check+0x98/0xd8\n security_bprm_check+0x5c/0x78\n search_binary_handler+0x6c/0x318\n exec_binprm+0x58/0x1b8\n bprm_execve+0xb8/0x130\n do_execveat_common.isra.0+0x1a8/0x258\n __arm64_sys_execve+0x48/0x68\n invoke_syscall+0x50/0x128\n el0_svc_common.constprop.0+0xc8/0xf0\n do_el0_svc+0x24/0x38\n el0_svc+0x44/0x200\n el0t_64_sync_handler+0x100/0x130\n el0t_64_sync+0x3c8/0x3d0\n\nFix this by changing \u0026apos;if (!rc)\u0026apos; to \u0026apos;if (rc \u0026lt;= 0)\u0026apos; to ensure that error\ncodes like -ENOENT do not bypass the check and accidentally result in a\nsuccessful match.(CVE-2025-68740)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix invalid prog-\u0026gt;stats access when update_effective_progs fails\n\nSyzkaller triggers an invalid memory access issue following fault\ninjection in update_effective_progs. The issue can be described as\nfollows:\n\n__cgroup_bpf_detach\n update_effective_progs\n compute_effective_progs\n bpf_prog_array_alloc \u0026lt;-- fault inject\n purge_effective_progs\n /* change to dummy_bpf_prog */\n array-\u0026gt;items[index] = \u0026amp;dummy_bpf_prog.prog\n\n---softirq start---\n__do_softirq\n ...\n __cgroup_bpf_run_filter_skb\n __bpf_prog_run_save_cb\n bpf_prog_run\n stats = this_cpu_ptr(prog-\u0026gt;stats)\n /* invalid memory access */\n flags = u64_stats_update_begin_irqsave(\u0026amp;stats-\u0026gt;syncp)\n---softirq end---\n\n static_branch_dec(\u0026amp;cgroup_bpf_enabled_key[atype])\n\nThe reason is that fault injection caused update_effective_progs to fail\nand then changed the original prog into dummy_bpf_prog.prog in\npurge_effective_progs. Then a softirq came, and accessing the members of\ndummy_bpf_prog.prog in the softirq triggers invalid mem access.\n\nTo fix it, skip updating stats when stats is NULL.(CVE-2025-68742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nethtool: Avoid overflowing userspace buffer on stats query\n\nThe ethtool -S command operates across three ioctl calls:\nETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and\nETHTOOL_GSTATS for the values.\n\nIf the number of stats changes between these calls (e.g., due to device\nreconfiguration), userspace\u0026apos;s buffer allocation will be incorrect,\npotentially leading to buffer overflow.\n\nDrivers are generally expected to maintain stable stat counts, but some\ndrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making\nthis scenario possible.\n\nSome drivers try to handle this internally:\n- bnad_get_ethtool_stats() returns early in case stats.n_stats is not\n equal to the driver\u0026apos;s stats count.\n- micrel/ksz884x also makes sure not to write anything beyond\n stats.n_stats and overflow the buffer.\n\nHowever, both use stats.n_stats which is already assigned with the value\nreturned from get_sset_count(), hence won\u0026apos;t solve the issue described\nhere.\n\nChange ethtool_get_strings(), ethtool_get_stats(),\nethtool_get_phy_stats() to not return anything in case of a mismatch\nbetween userspace\u0026apos;s size and get_sset_size(), to prevent buffer\noverflow.\nThe returned n_stats value will be equal to zero, to reflect that\nnothing has been returned.\n\nThis could result in one of two cases when using upstream ethtool,\ndepending on when the size change is detected:\n1. When detected in ethtool_get_strings():\n # ethtool -S eth2\n no stats available\n\n2. When detected in get stats, all stats will be reported as zero.\n\nBoth cases are presumably transient, and a subsequent ethtool call\nshould succeed.\n\nOther than the overflow avoidance, these two cases are very evident (no\noutput/cleared stats), which is arguably better than presenting\nincorrect/shifted stats.\nI also considered returning an error instead of a \u0026quot;silent\u0026quot; response, but\nthat seems more destructive towards userspace apps.\n\nNotes:\n- This patch does not claim to fix the inherent race, it only makes sure\n that we do not overflow the userspace buffer, and makes for a more\n predictable behavior.\n\n- RTNL lock is held during each ioctl, the race window exists between\n the separate ioctl calls when the lock is released.\n\n- Userspace ethtool always fills stats.n_stats, but it is likely that\n these stats ioctls are implemented in other userspace applications\n which might not fill it. The added code checks that it\u0026apos;s not zero,\n to prevent any regressions.(CVE-2025-68795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: xattr: fix null pointer deref in ext4_raw_inode()\n\nIf ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),\niloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()\nlacks error checking, this will lead to a null pointer dereference\nin ext4_raw_inode(), called right after ext4_get_inode_loc().\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: using the num_tqps in the vf driver to apply for resources\n\nCurrently, hdev-\u0026gt;htqp is allocated using hdev-\u0026gt;num_tqps, and kinfo-\u0026gt;tqp\nis allocated using kinfo-\u0026gt;num_tqps. However, kinfo-\u0026gt;num_tqps is set to\nmin(new_tqps, hdev-\u0026gt;num_tqps); Therefore, kinfo-\u0026gt;num_tqps may be smaller\nthan hdev-\u0026gt;num_tqps, which causes some hdev-\u0026gt;htqp[i] to remain\nuninitialized in hclgevf_knic_setup().\n\nThus, this patch allocates hdev-\u0026gt;htqp and kinfo-\u0026gt;tqp using hdev-\u0026gt;num_tqps,\nensuring that the lengths of hdev-\u0026gt;htqp and kinfo-\u0026gt;tqp are consistent\nand that all elements are properly initialized.(CVE-2025-71064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset\n\n`qfq_class-\u0026gt;leaf_qdisc-\u0026gt;q.qlen \u0026gt; 0` does not imply that the class\nitself is active.\n\nTwo qfq_class objects may point to the same leaf_qdisc. This happens\nwhen:\n\n1. one QFQ qdisc is attached to the dev as the root qdisc, and\n\n2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()\n/ qdisc_put()) and is pending to be destroyed, as in function\ntc_new_tfilter.\n\nWhen packets are enqueued through the root QFQ qdisc, the shared\nleaf_qdisc-\u0026gt;q.qlen increases. At the same time, the second QFQ\nqdisc triggers qdisc_put and qdisc_destroy: the qdisc enters\nqfq_reset() with its own q-\u0026gt;q.qlen == 0, but its class\u0026apos;s leaf\nqdisc-\u0026gt;q.qlen \u0026gt; 0. Therefore, the qfq_reset would wrongly deactivate\nan inactive aggregate and trigger a null-deref in qfq_deactivate_agg:\n\n[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 0.903571] #PF: supervisor write access in kernel mode\n[ 0.903860] #PF: error_code(0x0002) - not-present page\n[ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0\n[ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI\n[ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE\n[ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n[ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))\n[ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0\n\nCode starting with the faulting instruction\n===========================================\n 0:\t0f 84 4d 01 00 00 \tje 0x153\n 6:\t48 89 70 18 \tmov %rsi,0x18(%rax)\n a:\t8b 4b 10 \tmov 0x10(%rbx),%ecx\n d:\t48 c7 c2 ff ff ff ff \tmov $0xffffffffffffffff,%rdx\n 14:\t48 8b 78 08 \tmov 0x8(%rax),%rdi\n 18:\t48 d3 e2 \tshl %cl,%rdx\n 1b:\t48 21 f2 \tand %rsi,%rdx\n 1e:\t48 2b 13 \tsub (%rbx),%rdx\n 21:\t48 8b 30 \tmov (%rax),%rsi\n 24:\t48 d3 ea \tshr %cl,%rdx\n 27:\t8b 4b 18 \tmov 0x18(%rbx),%ecx\n\t...\n[ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246\n[ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000\n[ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000\n[ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000\n[ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880\n[ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000\n[ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0\n[ 0.910247] PKRU: 55555554\n[ 0.910391] Call Trace:\n[ 0.910527] \u0026lt;TASK\u0026gt;\n[ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)\n[ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)\n[ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)\n[ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)\n[ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\n[ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)\n[ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n[ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n[ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)\n[ 0.912484] netlink_sendmsg (net/netlink/af\n---truncated---(CVE-2026-22976)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix reference count leak in bpf_prog_test_run_xdp()\n\nsyzbot is reporting\n\n unregister_netdevice: waiting for sit0 to become free. Usage count = 2\n\nproblem. A debug printk() patch found that a refcount is obtained at\nxdp_convert_md_to_buff() from bpf_prog_test_run_xdp().\n\nAccording to commit ec94670fcb3b (\u0026quot;bpf: Support specifying ingress via\nxdp_md context in BPF_PROG_TEST_RUN\u0026quot;), the refcount obtained by\nxdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md().\n\nTherefore, we can consider that the error handling path introduced by\ncommit 1c1949982524 (\u0026quot;bpf: introduce frags support to\nbpf_prog_test_run_xdp()\u0026quot;) forgot to call xdp_convert_buff_to_md().(CVE-2026-22994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a deadlock involving nfs_release_folio()\n\nWang Zhaolong reports a deadlock involving NFSv4.1 state recovery\nwaiting on kthreadd, which is attempting to reclaim memory by calling\nnfs_release_folio(). The latter cannot make progress due to state\nrecovery being needed.\n\nIt seems that the only safe thing to do here is to kick off a writeback\nof the folio, without waiting for completion, or else kicking off an\nasynchronous commit.(CVE-2026-23053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuacce: implement mremap in uacce_vm_ops to return -EPERM\n\nThe current uacce_vm_ops does not support the mremap operation of\nvm_operations_struct. Implement .mremap to return -EPERM to remind\nusers.\n\nThe reason we need to explicitly disable mremap is that when the\ndriver does not implement .mremap, it uses the default mremap\nmethod. This could lead to a risk scenario:\n\nAn application might first mmap address p1, then mremap to p2,\nfollowed by munmap(p1), and finally munmap(p2). Since the default\nmremap copies the original vma\u0026apos;s vm_private_data (i.e., q) to the\nnew vma, both munmap operations would trigger vma_close, causing\nq-\u0026gt;qfr to be freed twice(qfr will be set to null here, so repeated\nrelease is ok).(CVE-2026-23056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuacce: ensure safe queue release with state management\n\nDirectly calling `put_queue` carries risks since it cannot\nguarantee that resources of `uacce_queue` have been fully released\nbeforehand. So adding a `stop_queue` operation for the\nUACCE_CMD_PUT_Q command and leaving the `put_queue` operation to\nthe final resource release ensures safety.\n\nQueue states are defined as follows:\n- UACCE_Q_ZOMBIE: Initial state\n- UACCE_Q_INIT: After opening `uacce`\n- UACCE_Q_STARTED: After `start` is issued via `ioctl`\n\nWhen executing `poweroff -f` in virt while accelerator are still\nworking, `uacce_fops_release` and `uacce_remove` may execute\nconcurrently. This can cause `uacce_put_queue` within\n`uacce_fops_release` to access a NULL `ops` pointer. Therefore, add\nstate checks to prevent accessing freed pointers.(CVE-2026-23063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-core: fix wrong reinitialization of ringbuffer on reopen\n\ndvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the\nDVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which\nreinitializes the waitqueue list head to empty.\n\nSince dmxdev-\u0026gt;dvr_buffer.queue is a shared waitqueue (all opens of the\nsame DVR device share it), this orphans any existing waitqueue entries\nfrom io_uring poll or epoll, leaving them with stale prev/next pointers\nwhile the list head is reset to {self, self}.\n\nThe waitqueue and spinlock in dvr_buffer are already properly\ninitialized once in dvb_dmxdev_init(). The open path only needs to\nreset the buffer data pointer, size, and read/write positions.\n\nReplace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct\nassignment of data/size and a call to dvb_ringbuffer_reset(), which\nproperly resets pread, pwrite, and error with correct memory ordering\nwithout touching the waitqueue or spinlock.(CVE-2026-23253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregmap: maple: free entry on mas_store_gfp() failure\n\nregcache_maple_write() allocates a new block (\u0026apos;entry\u0026apos;) to merge\nadjacent ranges and then stores it with mas_store_gfp().\nWhen mas_store_gfp() fails, the new \u0026apos;entry\u0026apos; remains allocated and\nis never freed, leaking memory.\n\nFree \u0026apos;entry\u0026apos; on the failure path; on success continue freeing the\nreplaced neighbor blocks (\u0026apos;lower\u0026apos;, \u0026apos;upper\u0026apos;).(CVE-2026-23260)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix unprivileged local user can do privileged policy management\n\nAn unprivileged local user can load, replace, and remove profiles by\nopening the apparmorfs interfaces, via a confused deputy attack, by\npassing the opened fd to a privileged process, and getting the\nprivileged process to write to the interface.\n\nThis does require a privileged target that can be manipulated to do\nthe write for the unprivileged process, but once such access is\nachieved full policy management is possible and all the possible\nimplications that implies: removing confinement, DoS of system or\ntarget applications by denying all execution, by-passing the\nunprivileged user namespace restriction, to exploiting kernel bugs for\na local privilege escalation.\n\nThe policy management interface can not have its permissions simply\nchanged from 0666 to 0600 because non-root processes need to be able\nto load policy to different policy namespaces.\n\nInstead ensure the task writing the interface has privileges that\nare a subset of the task that opened the interface. This is already\ndone via policy for confined processes, but unconfined can delegate\naccess to the opened fd, by-passing the usual policy check.(CVE-2026-23268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix __perf_event_overflow() vs perf_remove_from_context() race\n\nMake sure that __perf_event_overflow() runs with IRQs disabled for all\npossible callchains. Specifically the software events can end up running\nit with only preemption disabled.\n\nThis opens up a race vs perf_event_exit_event() and friends that will go\nand free various things the overflow path expects to be present, like\nthe BPF program.(CVE-2026-23271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: observe an RCU grace period in macvlan_common_newlink() error path\n\nvalis reported that a race condition still happens after my prior patch.\n\nmacvlan_common_newlink() might have made @dev visible before\ndetecting an error, and its caller will directly call free_netdev(dev).\n\nWe must respect an RCU period, either in macvlan or the core networking\nstack.\n\nAfter adding a temporary mdelay(1000) in macvlan_forward_source_one()\nto open the race window, valis repro was:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\nip link add mv0 link p2 type macvlan mode source\n\n(ip link add invalid% link p2 type macvlan mode source macaddr add\n00:00:00:00:00:20 \u0026amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4\nPING 1.2.3.4 (1.2.3.4): 56 data bytes\nRTNETLINK answers: Invalid argument\n\nBUG: KASAN: slab-use-after-free in macvlan_forward_source\n(drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nRead of size 8 at addr ffff888016bb89c0 by task e/175\n\nCPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n\u0026lt;IRQ\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:123)\nprint_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nkasan_report (mm/kasan/report.c:597)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nmacvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\n? tasklet_init (kernel/softirq.c:983)\nmacvlan_handle_frame (drivers/net/macvlan.c:501)\n\nAllocated by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\n__kasan_kmalloc (mm/kasan/common.c:419)\n__kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657\nmm/slub.c:7140)\nalloc_netdev_mqs (net/core/dev.c:12012)\nrtnl_create_link (net/core/rtnetlink.c:3648)\nrtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)\n\nFreed by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\nkasan_save_free_info (mm/kasan/generic.c:587)\n__kasan_slab_free (mm/kasan/common.c:287)\nkfree (mm/slub.c:6674 mm/slub.c:6882)\nrtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)(CVE-2026-23273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: reject mount if bigalloc with s_first_data_block != 0\n\nbigalloc with s_first_data_block != 0 is not supported, reject mounting\nit.(CVE-2026-31447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Check to ensure report responses match the request\n\nIt is possible for a malicious (or clumsy) device to respond to a\nspecific report\u0026apos;s feature request using a completely different report\nID. This can cause confusion in the HID core resulting in nasty\nside-effects such as OOB writes.\n\nAdd a check to ensure that the report ID in the response, matches the\none that was requested. If it doesn\u0026apos;t, omit reporting the raw event and\nreturn early.(CVE-2026-43047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Mitigate potential OOB by removing bogus memset()\n\nThe memset() in hid_report_raw_event() has the good intention of\nclearing out bogus data by zeroing the area from the end of the incoming\ndata string to the assumed end of the buffer. However, as we have\npreviously seen, doing so can easily result in OOB reads and writes in\nthe subsequent thread of execution.\n\nThe current suggestion from one of the HID maintainers is to remove the\nmemset() and simply return if the incoming event buffer size is not\nlarge enough to fill the associated report.\n\nSuggested-by Benjamin Tissoires \u0026lt;(CVE-2026-43048)\n\nIn the Linux kernel, there is a potential out-of-bounds access vulnerability in the ceph_handle_auth_reply() function of the libceph component. When processing messages of type CEPH_MSG_AUTH_REPLY, the value of the payload_len field is stored in a variable of type int. A value greater than INT_MAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)",
"id": "OESA-2026-2417",
"modified": "2026-08-06T11:11:22Z",
"published": "2026-05-22T11:11:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2417"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21908"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21970"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21980"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21986"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22009"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37740"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37748"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37766"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37768"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37770"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37771"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37778"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37793"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37815"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37831"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37918"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38037"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38043"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38113"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38122"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38123"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38161"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38183"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38193"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38255"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38307"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38344"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38364"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38461"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38462"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38488"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38499"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38552"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38575"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38609"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38721"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39682"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39770"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39812"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39937"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39980"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40136"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40240"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40281"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40331"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68283"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68740"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68742"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68820"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23253"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23260"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23268"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31447"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43047"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43407"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56611",
"CVE-2024-56760",
"CVE-2025-21908",
"CVE-2025-21931",
"CVE-2025-21970",
"CVE-2025-21971",
"CVE-2025-21980",
"CVE-2025-21981",
"CVE-2025-21986",
"CVE-2025-21995",
"CVE-2025-22001",
"CVE-2025-22009",
"CVE-2025-22071",
"CVE-2025-22077",
"CVE-2025-23138",
"CVE-2025-23157",
"CVE-2025-37740",
"CVE-2025-37748",
"CVE-2025-37766",
"CVE-2025-37768",
"CVE-2025-37770",
"CVE-2025-37771",
"CVE-2025-37778",
"CVE-2025-37793",
"CVE-2025-37805",
"CVE-2025-37815",
"CVE-2025-37831",
"CVE-2025-37844",
"CVE-2025-37853",
"CVE-2025-37881",
"CVE-2025-37889",
"CVE-2025-37905",
"CVE-2025-37918",
"CVE-2025-37947",
"CVE-2025-37967",
"CVE-2025-38014",
"CVE-2025-38037",
"CVE-2025-38043",
"CVE-2025-38051",
"CVE-2025-38064",
"CVE-2025-38113",
"CVE-2025-38122",
"CVE-2025-38123",
"CVE-2025-38131",
"CVE-2025-38148",
"CVE-2025-38161",
"CVE-2025-38183",
"CVE-2025-38193",
"CVE-2025-38194",
"CVE-2025-38241",
"CVE-2025-38255",
"CVE-2025-38304",
"CVE-2025-38307",
"CVE-2025-38321",
"CVE-2025-38344",
"CVE-2025-38364",
"CVE-2025-38461",
"CVE-2025-38462",
"CVE-2025-38488",
"CVE-2025-38499",
"CVE-2025-38552",
"CVE-2025-38575",
"CVE-2025-38609",
"CVE-2025-38721",
"CVE-2025-39676",
"CVE-2025-39682",
"CVE-2025-39702",
"CVE-2025-39728",
"CVE-2025-39756",
"CVE-2025-39770",
"CVE-2025-39812",
"CVE-2025-39841",
"CVE-2025-39894",
"CVE-2025-39937",
"CVE-2025-39955",
"CVE-2025-39980",
"CVE-2025-40018",
"CVE-2025-40062",
"CVE-2025-40078",
"CVE-2025-40136",
"CVE-2025-40240",
"CVE-2025-40254",
"CVE-2025-40280",
"CVE-2025-40281",
"CVE-2025-40331",
"CVE-2025-68283",
"CVE-2025-68284",
"CVE-2025-68285",
"CVE-2025-68304",
"CVE-2025-68740",
"CVE-2025-68742",
"CVE-2025-68795",
"CVE-2025-68820",
"CVE-2025-71064",
"CVE-2026-22976",
"CVE-2026-22994",
"CVE-2026-23053",
"CVE-2026-23056",
"CVE-2026-23063",
"CVE-2026-23253",
"CVE-2026-23260",
"CVE-2026-23268",
"CVE-2026-23271",
"CVE-2026-23273",
"CVE-2026-31447",
"CVE-2026-43047",
"CVE-2026-43048",
"CVE-2026-43407"
]
}
oesa-2026-2581
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: Prevent parser TCAM memory corruption
Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications.
Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row.
This issue was detected in a situation where mvpp2_set_rx_mode() ran
concurrently on two CPUs. In this particular case the
MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the
classifier unit to drop all incoming unicast - indicated by the
rx_classifier_drops counter.(CVE-2025-22060)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix NULL pointer in can_accept_new_subflow
When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL.
Call trace:
mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ...
According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons.
Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here.
This patch fixes this issue by moving the 'subflow_req->msk' under the
own_req == true conditional.
Note that the !msk check in subflow_hmac_valid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to.(CVE-2025-23145)
In the Linux kernel, the following vulnerability has been resolved:
mISDN: hfcpci: Fix warning when deleting uninitialized timer
With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads to the following splat:
[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDN_core [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] <TASK> [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130 [ 250.237920] debug_object_assert_init+0x1f6/0x310 [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __try_to_del_timer_sync+0x69/0x140 [ 250.241172] ? __pfxtryto_del_timer_sync+0x10/0x10 [ 250.242058] ? timer_delete_sync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timer_delete_sync+0xc6/0x120 [ 250.244262] __timer_delete_sync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] __do_sys_delete_module+0x348/0x510 [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10 [ 250.247338] do_syscall_64+0xc1/0x360 [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix this by initializing hfc_tl timer with DEFINE_TIMER macro. Also, use mod_timer instead of manual timeout update.(CVE-2025-39833)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Add support for Van Gogh SoC
The ROG Xbox Ally (non-X) SoC features a similar architecture to the Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash), this support was dropped by the Xbox Ally which only S0ix suspend.
Since the handler is missing here, this causes the device to not suspend and the AMD GPU driver to crash while trying to resume afterwards due to a power hang.(CVE-2025-68334)
In the Linux kernel, the following vulnerability has been resolved:
team: Move team device type change at the end of team_port_add
Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops.
In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change.
Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team.
Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1
Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail.
Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev
This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu.
Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot(CVE-2025-68340)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: asix: validate PHY address before use
The ASIX driver reads the PHY address from the USB device via asix_read_phy_addr(). A malicious or faulty device can return an invalid address (>= PHY_MAX_ADDR), which causes a warning in mdiobus_get_phy():
addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76
Validate the PHY address in asix_read_phy_addr() and remove the now-redundant check in ax88172a.c.(CVE-2025-71094)
In the Linux kernel, the following vulnerability has been resolved:
ip6_gre: make ip6gre_header() robust
Over the years, syzbot found many ways to crash the kernel in ip6gre_header() [1].
This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len
In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ip6gre device.
[1] skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! <TASK> skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693(CVE-2025-71098)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: add VLAN id validation before using
Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLAN_N_VID.
Therefore, VLAN id needs to be checked to ensure it is within the range of VLAN_N_VID.(CVE-2025-71112)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix string copying in parse_apply_sb_mount_options()
strscpy_pad() can't be used to copy a non-NUL-term string into a NUL-term string of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introduce memtostr() and memtostr_pad()") provides additional information in that regard. So if this happens, the following warning is observed:
strnlen: detected buffer overflow: 65 byte read of buffer size 64 WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032 Modules linked in: CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032 Call Trace: <TASK> __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sized_strscpy include/linux/fortify-string.h:309 [inline] parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline] __ext4_fill_super fs/ext4/super.c:5261 [inline] ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706 get_tree_bdev_flags+0x387/0x620 fs/super.c:1636 vfs_get_tree+0x93/0x380 fs/super.c:1814 do_new_mount fs/namespace.c:3553 [inline] path_mount+0x6ae/0x1f70 fs/namespace.c:3880 do_mount fs/namespace.c:3893 [inline] __do_sys_mount fs/namespace.c:4103 [inline] __se_sys_mount fs/namespace.c:4080 [inline] __x64_sys_mount+0x280/0x300 fs/namespace.c:4080 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Since userspace is expected to provide s_mount_opts field to be at most 63 characters long with the ending byte being NUL-term, use a 64-byte buffer which matches the size of s_mount_opts, so that strscpy_pad() does its job properly. Return with error if the user still managed to provide a non-NUL-term string here.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-71123)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer
Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb->vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below.
During the execution of eb_lookup_vmas(), the eb->vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer.
If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail.
In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is set to NULL, which is a source of a NULL deref bug described in the issue linked in the Closes tag.
When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the eb_release_vmas() function only recognizes NULL as the stopping value, hence the pointers are being set to NULL as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure.
(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)(CVE-2025-71130)
In the Linux kernel, the following vulnerability has been resolved:
smc91x: fix broken irq-context in PREEMPT_RT
When smc91x.c is built with PREEMPT_RT, the following splat occurs in FVP_RevC:
[ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000 [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106] [ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work [ 13.062266] C ** replaying previous printk message ** [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)} [ 13.062353] Hardware name: , BIOS [ 13.062382] Workqueue: mld mld_ifc_work [ 13.062469] Call trace: [ 13.062494] show_stack+0x24/0x40 (C) [ 13.062602] __dump_stack+0x28/0x48 [ 13.062710] dump_stack_lvl+0x7c/0xb0 [ 13.062818] dump_stack+0x18/0x34 [ 13.062926] process_scheduled_works+0x294/0x450 [ 13.063043] worker_thread+0x260/0x3d8 [ 13.063124] kthread+0x1c4/0x228 [ 13.063235] ret_from_fork+0x10/0x20
This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT, but smc_special_unlock() does not restore IRQs on PREEMPT_RT. The reason is that smc_special_unlock() calls spin_unlock_irqrestore(), and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke rcu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero.
To address this issue, replace smc_special_trylock() with spin_trylock_irqsave().(CVE-2025-71132)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: avoid chain re-validation if possible
Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate():
watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..]
Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps). But there are cases where we could avoid revalidation.
Consider: 1 input -> j2 -> j3 2 input -> j2 -> j3 3 input -> j1 -> j2 -> j3
Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3.
This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size. We also need to update all reachable chains with the new largest observed call depth.
Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains. For example, the masquerade expression can only be called from NAT postrouting base chains.
Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location.(CVE-2025-71160)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock in wait_current_trans() due to ignored transaction type
When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans().
This can lead to a deadlock scenario involving two transactions and pending ordered extents:
-
Transaction A is in TRANS_STATE_COMMIT_DOING state
-
A worker processing an ordered extent calls start_transaction() with TRANS_JOIN
-
join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING
-
Transaction A moves to TRANS_STATE_UNBLOCKED and completes
-
A new Transaction B is created (TRANS_STATE_RUNNING)
-
The ordered extent from step 2 is added to Transaction B's pending ordered extents
-
Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START
-
The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally
-
However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[]
-
Transaction B is waiting for pending ordered extents to complete
-
Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B
This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!)
Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents:
__schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Task kworker in wait_current_trans waiting for transaction commit:
Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30
Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.(CVE-2025-71194)
In the Linux kernel, the following vulnerability has been resolved:
iommu/sva: invalidate stale IOTLB entries for kernel address space
Introduce a new IOMMU interface to flush IOTLB paging cache entries for the CPU kernel address space. This interface is invoked from the x86 architecture code that manages combined user and kernel page tables, specifically before any kernel page table page is freed and reused.
This addresses the main issue with vfree() which is a common occurrence and can be triggered by unprivileged users. While this resolves the primary problem, it doesn't address some extremely rare case related to memory unplug of memory that was present as reserved memory at boot, which cannot be triggered by unprivileged users. The discussion can be found at the link below.
Enable SVA on x86 architecture since the IOMMU can now receive notification to flush the paging cache before freeing the CPU kernel page table pages.(CVE-2025-71202)
In the Linux kernel, the following vulnerability has been resolved:
audit: add fchmodat2() to change attributes class
fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as:
-w /tmp/test -p rwa -k test_rwa
The current patch adds fchmodat2() to the change attributes class.(CVE-2025-71239)
In the Linux kernel, the following vulnerability has been resolved:
macvlan: fix possible UAF in macvlan_forward_source()
Add RCU protection on (struct macvlan_source_entry)->vlan.
Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts.
This allows macvlan_forward_source() to skip over entries queued for freeing.
Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)).
https: //lore.kernel.org/netdev/(CVE-2026-23001)
In the Linux kernel, the following vulnerability has been resolved:
uacce: ensure safe queue release with state management
Directly calling put_queue carries risks since it cannot
guarantee that resources of uacce_queue have been fully released
beforehand. So adding a stop_queue operation for the
UACCE_CMD_PUT_Q command and leaving the put_queue operation to
the final resource release ensures safety.
Queue states are defined as follows:
- UACCE_Q_ZOMBIE: Initial state
- UACCE_Q_INIT: After opening uacce
- UACCE_Q_STARTED: After start is issued via ioctl
When executing poweroff -f in virt while accelerator are still
working, uacce_fops_release and uacce_remove may execute
concurrently. This can cause uacce_put_queue within
uacce_fops_release to access a NULL ops pointer. Therefore, add
state checks to prevent accessing freed pointers.(CVE-2026-23063)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Enforce that teql can only be used as root qdisc
Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.
Although not important, I will describe the scenario that unearthed this issue for the curious.
GangMin Kim <(CVE-2026-23074)
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: signal: Fix restoration of SVE context
When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.
(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL.
This can only occur in unusual (but legitimate) cases where the SVE
signal context has either been modified by userspace or was saved in
the context of another task (e.g. as with CRIU), as otherwise the
presence of an SVE signal context with SVE_SIG_FLAG_SM implies that
TIF_SME is already set.
While in this state, task_fpsimd_load() will NOT configure SMCR_ELx
(leaving some arbitrary value configured in hardware) before
restoring SVCR and attempting to restore the streaming mode SVE
registers from memory via sve_load_state(). As the value of
SMCR_ELx.LEN may be larger than the task's streaming SVE vector
length, this may read memory outside of the task's allocated
sve_state, reading unrelated data and/or triggering a fault.
While this can result in secrets being loaded into streaming SVE
registers, these values are never exposed. As TIF_SME is clear,
fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0
accesses to streaming mode SVE registers, so these cannot be
accessed directly at EL0. As fpsimd_save_user_state() verifies the
live vector length before saving (S)SVE state to memory, no secret
values can be saved back to memory (and hence cannot be observed via
ptrace, signals, etc).
When the live vector length doesn't match the expected vector length
for the task, fpsimd_save_user_state() will send a fatal SIGKILL
signal to the task. Hence the task may be killed after executing
userspace for some period of time.
(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV.
This can only occur in unusual (but legitimate) cases where ptrace
has been used to set SVCR.SM after entry to the sigreturn syscall,
as syscall entry clears SVCR.SM.
In these cases, the the provided SVE register data will be loaded
into the task's sve_state using the non-streaming SVE vector length
and the FPSIMD registers will be merged into this using the
streaming SVE vector length.
Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.
For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.(CVE-2026-23102)
In the Linux kernel, the following vulnerability has been resolved:
mm/shmem, swap: fix race of truncate and swap entry split
The helper for shmem swap freeing is not handling the order of swap entries correctly. It uses xa_cmpxchg_irq to erase the swap entry, but it gets the entry order before that using xa_get_order without lock protection, and it may get an outdated order value if the entry is split or changed in other ways after the xa_get_order and before the xa_cmpxchg_irq.
And besides, the order could grow and be larger than expected, and cause truncation to erase data beyond the end border. For example, if the target entry and following entries are swapped in or freed, then a large folio was added in place and swapped out, using the same entry, the xa_cmpxchg_irq will still succeed, it's very unlikely to happen though.
To fix that, open code the Xarray cmpxchg and put the order retrieval and value checking in the same critical section. Also, ensure the order won't exceed the end border, skip it if the entry goes across the border.
Skipping large swap entries crosses the end border is safe here. Shmem truncate iterates the range twice, in the first iteration, find_lock_entries already filtered such entries, and shmem will swapin the entries that cross the end border and partially truncate the folio (split the folio or at least zero part of it). So in the second loop here, if we see a swap entry that crosses the end order, it must at least have its content erased already.
I observed random swapoff hangs and kernel panics when stress testing ZSWAP with shmem. After applying this patch, all problems are gone.(CVE-2026-23161)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/umad: Reject negative data_len in ib_umad_write
ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list().
Add an explicit check to reject negative data_len before creating the send buffer.
KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80(CVE-2026-23243)
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix memory allocation in nvme_pr_read_keys()
nvme_pr_read_keys() takes num_keys from userspace and uses it to calculate the allocation size for rse via struct_size(). The upper limit is PR_KEYS_MAX (64K).
A malicious or buggy userspace can pass a large num_keys value that results in a 4MB allocation attempt at most, causing a warning in the page allocator when the order exceeds MAX_PAGE_ORDER.
To fix this, use kvzalloc() instead of kzalloc().
This bug has the same reasoning and fix with the patch below: https://lore.kernel.org/linux-block/(CVE-2026-23244)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: unconditionally bump set->nelems before insertion
In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already.
To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state.
As for element updates, decrement set->nelems to restore it.
A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.(CVE-2026-23272)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: kaweth: validate USB endpoints
The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.(CVE-2026-23312)
In the Linux kernel, the following vulnerability has been resolved:
net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs
When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used.
qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF.
This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs:
iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done
With KASAN enabled, this leads to reports like:
BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: <TASK> ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... </TASK>
Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ...
Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ...
Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue().
Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check
cdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE entries fit within the skb. The first check correctly accounts for ndpoffset:
if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len)
but the second check omits it:
if ((sizeof(struct usb_cdc_ncm_ndp16) + ret * (sizeof(struct usb_cdc_ncm_dpe16))) > skb_in->len)
This validates the DPE array size against the total skb length as if the NDP were at offset 0, rather than at ndpoffset. When the NDP is placed near the end of the NTB (large wNdpIndex), the DPE entries can extend past the skb data buffer even though the check passes. cdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating the DPE array.
Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly.(CVE-2026-23448)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2026-23473)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix krb5 mount with username option
Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials. It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts.
By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8. So fix this by matching username mount option in match_session() even with Kerberos.
For example, the second mount below should fail with -ENOKEY as there is no 'foobar' principal in keytab (/etc/krb5.keytab). The client ends up reusing SMB session from first mount to perform the second one, which is wrong.
$ ktutil
ktutil: add_entry -password -p testuser -k 1 -e aes256-cts
Password for (CVE-2026-31392)
In the Linux kernel, the following vulnerability has been resolved:
mm/rmap: fix incorrect pte restoration for lazyfree folios
We batch unmap anonymous lazyfree folios by folio_unmap_pte_batch. If the
batch has a mix of writable and non-writable bits, we may end up setting
the entire batch writable. Fix this by respecting writable bit during
batching.
Although on a successful unmap of a lazyfree folio, the soft-dirty bit is
lost, preserve it on pte restoration by respecting the bit during
batching, to make the fix consistent w.r.t both writable bit and
soft-dirty bit.
I was able to write the below reproducer and crash the kernel.
Explanation of reproducer (set 64K mTHP to always):
Fault in a 64K large folio. Split the VMA at mid-point with
MADV_DONTFORK. fork() - parent points to the folio with 8 writable ptes
and 8 non-writable ptes. Merge the VMAs with MADV_DOFORK so that
folio_unmap_pte_batch() can determine all the 16 ptes as a batch. Do
MADV_FREE on the range to mark the folio as lazyfree. Write to the memory
to dirty the pte, eventually rmap will dirty the folio. Then trigger
reclaim, we will hit the pte restoration path, and the kernel will crash
with the trace given below.
The BUG happens at:
BUG_ON(atomic_inc_return(&ptc->anon_map_count) > 1 && rw);
The code path is asking for anonymous page to be mapped writable into the
pagetable. The BUG_ON() firing implies that such a writable page has been
mapped into the pagetables of more than one process, which breaks
anonymous memory/CoW semantics.
[ 21.134473] kernel BUG at mm/page_table_check.c:118!
[ 21.134497] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 21.135917] Modules linked in:
[ 21.136085] CPU: 1 UID: 0 PID: 1735 Comm: dup-lazyfree Not tainted 7.0.0-rc1-00116-g018018a17770 #1028 PREEMPT
[ 21.136858] Hardware name: linux,dummy-virt (DT)
[ 21.137019] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 21.137308] pc : page_table_check_set+0x28c/0x2a8
[ 21.137607] lr : page_table_check_set+0x134/0x2a8
[ 21.137885] sp : ffff80008a3b3340
[ 21.138124] x29: ffff80008a3b3340 x28: fffffdffc3d14400 x27: ffffd1a55e03d000
[ 21.138623] x26: 0040000000000040 x25: ffffd1a55f7dd000 x24: 0000000000000001
[ 21.139045] x23: 0000000000000001 x22: 0000000000000001 x21: ffffd1a55f217f30
[ 21.139629] x20: 0000000000134521 x19: 0000000000134519 x18: 005c43e000040000
[ 21.140027] x17: 0001400000000000 x16: 0001700000000000 x15: 000000000000ffff
[ 21.140578] x14: 000000000000000c x13: 005c006000000000 x12: 0000000000000020
[ 21.140828] x11: 0000000000000000 x10: 005c000000000000 x9 : ffffd1a55c079ee0
[ 21.141077] x8 : 0000000000000001 x7 : 005c03e000040000 x6 : 000000004000ffff
[ 21.141490] x5 : ffff00017fffce00 x4 : 0000000000000001 x3 : 0000000000000002
[ 21.141741] x2 : 0000000000134510 x1 : 0000000000000000 x0 : ffff0000c08228c0
[ 21.141991] Call trace:
[ 21.142093] page_table_check_set+0x28c/0x2a8 (P)
[ 21.142265] __page_table_check_ptes_set+0x144/0x1e8
[ 21.142441] __set_ptes_anysz.constprop.0+0x160/0x1a8
[ 21.142766] contpte_set_ptes+0xe8/0x140
[ 21.142907] try_to_unmap_one+0x10c4/0x10d0
[ 21.143177] rmap_walk_anon+0x100/0x250
[ 21.143315] try_to_unmap+0xa0/0xc8
[ 21.143441] shrink_folio_list+0x59c/0x18a8
[ 21.143759] shrink_lruvec+0x664/0xbf0
[ 21.144043] shrink_node+0x218/0x878
[ 21.144285] __node_reclaim.constprop.0+0x98/0x338
[ 21.144763] user_proactive_reclaim+0x2a4/0x340
[ 21.145056] reclaim_store+0x3c/0x60
[ 21.145216] dev_attr_store+0x20/0x40
[ 21.145585] sysfs_kf_write+0x84/0xa8
[ 21.145835] kernfs_fop_write_iter+0x130/0x1c8
[ 21.145994] vfs_write+0x2b8/0x368
[ 21.146119] ksys_write+0x70/0x110
[ 21.146240] __arm64_sys_write+0x24/0x38
[ 21.146380] invoke_syscall+0x50/0x120
[ 21.146513] el0_svc_common.constprop.0+0x48/0xf8
[ 21.146679] do_el0_svc+0x28/0x40
[ 21.146798] el0_svc+0x34/0x110
[ 21.146926] el0t
---truncated---(CVE-2026-31398)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_fw: fix NULL pointer dereference on shared blocks
The old-method path in fw_classify() calls tcf_block_q() and
dereferences q->handle. Shared blocks leave block->q NULL, causing a
NULL deref when an empty cls_fw filter is attached to a shared block
and a packet with a nonzero major skb mark is classified.
Reject the configuration in fw_change() when the old method (no
TCA_OPTIONS) is used on a shared block, since fw_classify()'s
old-method path needs block->q which is NULL for shared blocks.
The fixed null-ptr-deref calling stack:
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
Call Trace:
tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
tc_run (net/core/dev.c:4401)
__dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)(CVE-2026-31421)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_flow: fix NULL pointer dereference on shared blocks
flow_change() calls tcf_block_q() and dereferences q->handle to derive
a default baseclass. Shared blocks leave block->q NULL, causing a NULL
deref when a flow filter without a fully qualified baseclass is created
on a shared block.
Check tcf_block_shared() before accessing block->q and return -EINVAL
for shared blocks. This avoids the null-deref shown below:
=======================================================================
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:flow_change (net/sched/cls_flow.c:508)
Call Trace:
tc_new_tfilter (net/sched/cls_api.c:2432)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)
[...]
=======================================================================(CVE-2026-31422)
In the Linux kernel, the following vulnerability has been resolved:
net: skb: fix cross-cache free of KFENCE-allocated skb head
SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2
value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc
bucket sizes. This ensures that skb_kfree_head() can reliably use
skb_end_offset to distinguish skb heads allocated from
skb_small_head_cache vs. generic kmalloc caches.
However, when KFENCE is enabled, kfence_ksize() returns the exact
requested allocation size instead of the slab bucket size. If a caller
(e.g. bpf_test_init) allocates skb head data via kzalloc() and the
requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then
slab_build_skb() -> ksize() returns that exact value. After subtracting
skb_shared_info overhead, skb_end_offset ends up matching
SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free
the object to skb_small_head_cache instead of back to the original
kmalloc cache, resulting in a slab cross-cache free:
kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected
skbuff_small_head but got kmalloc-1k
Fix this by always calling kfree(head) in skb_kfree_head(). This keeps
the free path generic and avoids allocator-specific misclassification
for KFENCE objects.(CVE-2026-31429)
In the Linux kernel, the following vulnerability has been resolved:
X.509: Fix out-of-bounds access when parsing extensions
Leo reports an out-of-bounds access when parsing a certificate with
empty Basic Constraints or Key Usage extension because the first byte of
the extension is read before checking its length. Fix it.
The bug can be triggered by an unprivileged user by submitting a
specially crafted certificate to the kernel through the keyrings(7) API.
Leo has demonstrated this with a proof-of-concept program responsibly
disclosed off-list.(CVE-2026-31430)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix memory leak when a wq is reset
idxd_wq_disable_cleanup() which is called from the reset path for a
workqueue, sets the wq type to NONE, which for other parts of the
driver mean that the wq is empty (all its resources were released).
Only set the wq type to NONE after its resources are released.(CVE-2026-31441)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix possible invalid memory access after FLR
In the case that the first Function Level Reset (FLR) concludes
correctly, but in the second FLR the scratch area for the saved
configuration cannot be allocated, it's possible for a invalid memory
access to happen.
Always set the deallocated scratch area to NULL after FLR completes.(CVE-2026-31442)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix use-after-free in update_super_work when racing with umount
Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
reads during unmount. However, this introduced a use-after-free because
update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
accesses the kobject's kernfs_node after it has been freed by kobject_del()
in ext4_unregister_sysfs():
update_super_work ext4_put_super
----------------- --------------
ext4_unregister_sysfs(sb)
kobject_del(&sbi->s_kobj)
__kobject_del()
sysfs_remove_dir()
kobj->sd = NULL
sysfs_put(sd)
kernfs_put() // RCU free
ext4_notify_error_sysfs(sbi)
sysfs_notify(&sbi->s_kobj)
kn = kobj->sd // stale pointer
kernfs_get(kn) // UAF on freed kernfs_node
ext4_journal_destroy()
flush_work(&sbi->s_sb_upd_work)
Instead of reordering the teardown sequence, fix this by making
ext4_notify_error_sysfs() detect that sysfs has already been torn down
by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call
in that case. A dedicated mutex (s_error_notify_mutex) serializes
ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()
to prevent TOCTOU races where the kobject could be deleted between the
state_in_sysfs check and the sysfs_notify() call.(CVE-2026-31446)
In the Linux kernel, the following vulnerability has been resolved:
ext4: validate p_idx bounds in ext4_ext_correct_indexes
ext4_ext_correct_indexes() walks up the extent tree correcting
index entries when the first extent in a leaf is modified. Before
accessing path[k].p_idx->ei_block, there is no validation that
p_idx falls within the valid range of index entries for that
level.
If the on-disk extent header contains a corrupted or crafted
eh_entries value, p_idx can point past the end of the allocated
buffer, causing a slab-out-of-bounds read.
Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at
both access sites: before the while loop and inside it. Return
-EFSCORRUPTED if the index pointer is out of range, consistent
with how other bounds violations are handled in the ext4 extent
tree code.(CVE-2026-31449)
In the Linux kernel, the following vulnerability has been resolved:
ext4: publish jinode after initialization
ext4_inode_attach_jinode() publishes ei->jinode to concurrent users.
It used to set ei->jinode before jbd2_journal_init_jbd_inode(),
allowing a reader to observe a non-NULL jinode with i_vfs_inode
still unset.
The fast commit flush path can then pass this jinode to
jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and
may crash.
Below is the crash I observe:
BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ```
Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.(CVE-2026-31450)
In the Linux kernel, the following vulnerability has been resolved:
ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio
Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption.
The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.(CVE-2026-31451)
In the Linux kernel, the following vulnerability has been resolved:
ext4: convert inline data to extents when truncate exceeds inline size
Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline.
Without this fix, the following sequence causes a kernel BUG_ON():
- Mount filesystem with inode that has inline flag set and small size
- truncate(file, 50MB) - grows size but inline flag remains set
- sendfile() attempts to write data
- ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity)
The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request.
The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change.
This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.(CVE-2026-31452)
In the Linux kernel, the following vulnerability has been resolved:
erofs: add GFP_NOIO in the bio completion if needed
The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL.
Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios.
Trimmed down the call stack, as follows:
f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!!
Use memalloc_noio_{save,restore}() to wrap up this path.(CVE-2026-31467)
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false
A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules).
When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period.
If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs.
fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net.
Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ...
Reproduction Steps: NETDEV="enp3s0"
config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \ protocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 }
test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns }
config_qdisc_route_filter
test_ns sleep 2 test_ns(CVE-2026-31469)
In the Linux kernel, the following vulnerability has been resolved:
spi: use generic driver_override infrastructure
When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.
Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.
Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
Also note that we do not enable the driver_override feature of struct bus_type, as SPI - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n".(CVE-2026-31487)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use netlink policy range checks
Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.
- CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check.
- CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count.
- CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks.
- CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags.
Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.(CVE-2026-31495)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_expect: skip expectations in other netns via proc
Skip expectations that do not reside in this netns.
Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc").(CVE-2026-31496)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop
l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources.
Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory.
Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.(CVE-2026-31498)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()
l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock.
Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del().(CVE-2026-31499)
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()
iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the value could change in runtime, we should use num_tx_queues instead.
Moreover iavf_get_ethtool_stats() uses num_active_queues while iavf_get_sset_count() and iavf_get_stat_strings() use real_num_tx_queues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1].
For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3:
Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavf_set_channels() ... iavf_alloc_queues() -> num_active_queues = 8 iavf_schedule_finish_config() iavf_get_sset_count() real_num_tx_queues: 1 -> buffer for 1 queue iavf_get_ethtool_stats() num_active_queues: 8 -> out-of-bounds! iavf_finish_config() -> real_num_tx_queues = 8
Use immutable num_tx_queues in all related functions to avoid the issue.
[1] BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800
CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK>
The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8(CVE-2026-31505)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb
Before using sk pointer, check if it is null.
Fix the following:
KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: <TASK> __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfxmutexlock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception(CVE-2026-31510)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete
This fixes the condition checking so mgmt_pending_valid is executed whenever status != -ECANCELED otherwise calling mgmt_pending_free(cmd) would kfree(cmd) without unlinking it from the list first, leaving a dangling pointer. Any subsequent list traversal (e.g., mgmt_pending_foreach during __mgmt_power_off, or another mgmt_pending_valid call) would dereference freed memory.(CVE-2026-31511)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()
l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb.
The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path.(CVE-2026-31512)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: prevent policy_hthresh.work from racing with netns teardown
A XFRM_MSG_NEWSPDINFO request can queue the per-net work item policy_hthresh.work onto the system workqueue.
The queued callback, xfrm_hash_rebuild(), retrieves the enclosing struct net via container_of(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrm_hash_rebuild() may then dereference stale memory.
xfrm_policy_fini() already flushes policy_hash_work during teardown, but it does not synchronize policy_hthresh.work.
Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.(CVE-2026-31516)
In the Linux kernel, the following vulnerability has been resolved:
esp: fix skb leak with espintcp and async crypto
When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us.
With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error.(CVE-2026-31518)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN
The BPF interpreter's signed 32-bit division and modulo handlers use the kernel abs() macro on s32 operands. The abs() macro documentation (include/linux/math.h) explicitly states the result is undefined when the input is the type minimum. When DST contains S32_MIN (0x80000000), abs((s32)DST) triggers undefined behavior and returns S32_MIN unchanged on arm64/x86. This value is then sign-extended to u64 as 0xFFFFFFFF80000000, causing do_div() to compute the wrong result.
The verifier's abstract interpretation (scalar32_min_max_sdiv) computes the mathematically correct result for range tracking, creating a verifier/interpreter mismatch that can be exploited for out-of-bounds map value access.
Introduce abs_s32() which handles S32_MIN correctly by casting to u32 before negating, avoiding signed overflow entirely. Replace all 8 abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers.
s32 is the only affected case -- the s64 division/modulo handlers do not use abs().(CVE-2026-31525)
In the Linux kernel, the following vulnerability has been resolved:
perf: Make sure to use pmu_ctx->pmu for groups
Oliver reported that x86_pmu_del() ended up doing an out-of-bound memory access when group_sched_in() fails and needs to roll back.
This should be handled by the transaction callbacks, but he found that when the group leader is a software event, the transaction handlers of the wrong PMU are used. Despite the move_group case in perf_event_open() and group_sched_in() using pmu_ctx->pmu.
Turns out, inherit uses event->pmu to clone the events, effectively undoing the move_group case for all inherited contexts. Fix this by also making inherit use pmu_ctx->pmu, ensuring all inherited counters end up in the same pmu context.
Similarly, __perf_event_read() should use equally use pmu_ctx->pmu for the group case.(CVE-2026-31528)
In the Linux kernel, the following vulnerability has been resolved:
can: raw: fix ro->uniq use-after-free in raw_rcv()
raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage.
Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained.
In the Linux kernel, the following vulnerability has been resolved:
net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption
The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry.
When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist.
The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record.
Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.(CVE-2026-31533)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Check set_default_submission() before deferencing
When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways.
Add a check to make sure it is set before dereferencing.
[ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] <TASK> [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] </TASK> [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------
(cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)(CVE-2026-31540)
In the Linux kernel, the following vulnerability has been resolved:
x86/platform/uv: Handle deconfigured sockets
When a socket is deconfigured, it's mapped to SOCK_EMPTY (0xffff). This causes a panic while allocating UV hub info structures.
Fix this by using NUMA_NO_NODE, allowing UV hub info structures to be allocated on valid nodes.(CVE-2026-31542)
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: fix NULL deref in bond_debug_rlb_hash_show
rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL.
Other used-list iterators in bond_alb.c already handle this NULL-slave state safely:
- rlb_update_client returns early on !client_info->slave
- rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting
- lb_req_update_subnet_clients continues if slave is NULL
The following NULL deref crash can be trigger in bond_debug_rlb_hash_show:
[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Add a NULL check and print "(none)" for entries with no assigned slave.(CVE-2026-31546)
In the Linux kernel, the following vulnerability has been resolved:
futex: Clear stale exiting pointer in futex_lock_pi() retry path
Fuzzying/stressing futexes triggered:
WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524
When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'.
After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting().
CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting)
Fix this by resetting upon retry, essentially aligning it with requeue_pi.(CVE-2026-31555)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib
amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence from amdgpu_ib_schedule(). This fence is used to wait for job completion.
Currently, the code drops the fence reference using dma_fence_put() before calling dma_fence_wait().
If dma_fence_put() releases the last reference, the fence may be freed before dma_fence_wait() is called. This can lead to a use-after-free.
Fix this by waiting on the fence first and releasing the reference only after dma_fence_wait() completes.
Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory 'f' (line 696)
(cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)(CVE-2026-31566)
In the Linux kernel, the following vulnerability has been resolved:
can: gw: fix OOB heap access in cgw_csum_crc8_rel()
cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():
int from = calc_idx(crc8->from_idx, cf->len);
int to = calc_idx(crc8->to_idx, cf->len);
int res = calc_idx(crc8->result_idx, cf->len);
if (from < 0 || to < 0 || res < 0)
return;
However, the loop and the result write then use the raw s8 fields directly instead of the computed variables:
for (i = crc8->from_idx; ...) /* BUG: raw negative index */
cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */
With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap.
The companion function cgw_csum_xor_rel() uses from/to/res
correctly throughout; fix cgw_csum_crc8_rel() to match.
Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62
To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.(CVE-2026-31570)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION
Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing:
struct kvm_enc_region range = { .addr = 0, .size = -1ul, };
__vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range);
Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both "addr" and "size" are u64s and SEV is 64-bit only, i.e. they can't be greater than ULONG_MAX. That wart will be cleaned up in the near future.
if (range->addr > ULONG_MAX || range->size > ULONG_MAX)
return -EINVAL;
Opportunistically add a comment to explain why the code calculates the number of pages the "hard" way, e.g. instead of just shifting @ulen.(CVE-2026-31590)
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup
Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down.
Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20(CVE-2026-31595)
In the Linux kernel, the following vulnerability has been resolved:
x86/CPU: Fix FPDSS on Zen1
Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread.
Fix that with a chicken bit.(CVE-2026-31628)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: proc: size address buffers for %pISpc output
The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc".
That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap().
As a result, a case such as
is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c.
Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf().
Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example(CVE-2026-31630)
In the Linux kernel, the following vulnerability has been resolved:
mmc: vub300: fix NULL-deref on disconnect
Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.(CVE-2026-31651)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: fix use-after-free in timeout object destroy
nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data().
Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c.
KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80
Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320
Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00
Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0(CVE-2026-31665)
In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - fix circular locking dependency with ff-core
A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller):
ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
The cycle is caused by four lock acquisition paths:
-
ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex.
-
device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex.
-
device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex.
-
evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes.
To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock.
Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible.
Lock ordering after the fix:
ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)(CVE-2026-31667)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_netem: fix out-of-bounds access in packet corruption
In netem_enqueue(), the packet corruption logic uses get_random_u32_below(skb_headlen(skb)) to select an index for modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.
Passing 0 to get_random_u32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access.
Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic.(CVE-2026-31675)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - limit RX SG extraction by receive buffer budget
Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget.
af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request.
If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.(CVE-2026-31677)
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: defer tunnel netdev_put to RCU release
ovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev.
Do not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, let vport_netdev_free() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL.(CVE-2026-31678)
In the Linux kernel, a memory out-of-bounds access vulnerability exists in the act_csum module's tcf_csum_act() function when processing nested VLAN headers. When an skb still carries in-payload VLAN tags, the function walks nested VLAN headers directly from skb->data. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants.(CVE-2026-31684)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6t_eui64: reject invalid MAC header for all packets
eui64_mt6() derives a modified EUI-64 from the Ethernet source address
and compares it with the low 64 bits of the IPv6 source address.
The existing guard only rejects an invalid MAC header when
par->fragoff != 0. For packets with par->fragoff == 0, eui64_mt6()
can still reach eth_hdr(skb) even when the MAC header is not valid.
Fix this by removing the par->fragoff != 0 condition so that packets
with an invalid MAC header are rejected before accessing eth_hdr(skb).(CVE-2026-31685)
In the Linux kernel, the following vulnerability has been resolved:
EDAC/mc: Fix error path ordering in edac_mc_alloc()
When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device's release function.
However, the init ordering is wrong such that device_initialize() happens after the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called:
MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: <TASK> edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ...
Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used.
This was found by Claude while reviewing another EDAC patch.(CVE-2026-31689)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed
When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388
CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31697)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed
When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033
CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31698)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed
When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405
CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31699)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path
smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len.
A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace.
Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.(CVE-2026-31708)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: validate ND option lengths in vxlan_na_create
vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.
Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.(CVE-2026-31738)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: gadget: fix NULL pointer dereference in ep_queue
When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash.
Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints.
This prevents potential crashes when ep_queue is called on endpoints that are not ready.(CVE-2026-31755)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: move wake reason storage into validated event handlers
hci_store_wake_reason() is called from hci_event_packet() immediately after stripping the HCI event header but before hci_event_func() enforces the per-event minimum payload length from hci_ev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs.
Rather than duplicating skb parsing and per-event length checks inside hci_store_wake_reason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hci_store_wake_reason() into a small helper that only stores an already-validated bdaddr while the caller holds hci_dev_lock(). Use the same helper after hci_event_func() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address.
Annotate the helper with __must_hold(&hdev->lock) and add lockdep_assert_held(&hdev->lock) so future call paths keep the lock contract explicit.
Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(), hci_sync_conn_complete_evt(), le_conn_complete_evt(), hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(), hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and hci_le_past_received_evt().(CVE-2026-31771)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SMP: derive legacy responder STK authentication from MITM state
The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved.
For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result.
This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.(CVE-2026-31773)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler()
The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-31779)
In the Linux kernel, the following vulnerability has been resolved:
drm/ioc32: stop speculation on the drm_compat_ioctl path
The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.(CVE-2026-31781)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: validate LTK enc_size on load
Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer.
Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.(CVE-2026-43020)
In the Linux kernel, the following vulnerability has been resolved:
net: use skb_header_pointer() for TCPv4 GSO frag_off check
Syzbot reported a KMSAN uninit-value warning in gso_features_check() called from netif_skb_features() [1].
gso_features_check() reads iph->frag_off to decide whether to clear mangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PF_PACKET paths.
Use skb_header_pointer() for the TCPv4 frag_off check so the header read is robust whether data is already linear or needs copying.
[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407(CVE-2026-43036)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak
When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data
The fix is simple, just zeroes the padding fields.(CVE-2026-43040)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af-alg - fix NULL pointer dereference in scatterwalk
The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry.
This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference.
Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().(CVE-2026-43043)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix not releasing workqueue on .release()
The workqueue associated with an DSA/IAA device is not released when the object is freed.(CVE-2026-43064)
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Skip discovery table for offline dies
This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0.
WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]
Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.(CVE-2026-43079)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()
As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array().(CVE-2026-43148)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE
The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this.(CVE-2026-43212)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: fiemap page fault fix
In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault.
Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary.
Fixes xfstest generic/742.(CVE-2026-43262)
In the Linux kernel, the following vulnerability has been resolved:
ceph: supply snapshot context in ceph_zero_partial_object()
The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots.
Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph (CVE-2026-43273)
In the Linux kernel, the following vulnerability has been resolved:
net: ipa: fix event ring index not programmed for IPA v5.0+
For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to CH_C_CNTXT_1. The v5.0 register definition intended to define this field in the CH_C_CNTXT_1 fmask array but used the old identifier of ERINDEX instead of CH_ERINDEX.
Without a valid event ring, GSI channels could never signal transfer completions. This caused gsi_channel_trans_quiesce() to block forever in wait_for_completion().
At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.(CVE-2026-43345)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix memory leaks in ceph_mdsc_build_path()
Add __putname() calls to error code paths that did not free the "path" pointer obtained by __getname(). If ownership of this pointer is not passed to the caller via path_info.path, the function must free it before returning.(CVE-2026-43419)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Limit the length of unkillable synchronous timeouts
The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.
To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.
In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)
In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. The Linux kernel CVE team has assigned CVE-2026-43493 to this issue.(CVE-2026-43493)
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker through frag-transfer helpers
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false.
The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes.
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker.
The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently.
The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.(CVE-2026-43503)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"perf-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.14.152.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.1.14.152.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"perf-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-145.1.14.152.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.14.152.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-145.1.14.152.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mvpp2: Prevent parser TCAM memory corruption\n\nProtect the parser TCAM/SRAM memory, and the cached (shadow) SRAM\ninformation, from concurrent modifications.\n\nBoth the TCAM and SRAM tables are indirectly accessed by configuring\nan index register that selects the row to read or write to. This means\nthat operations must be atomic in order to, e.g., avoid spreading\nwrites across multiple rows. Since the shadow SRAM array is used to\nfind free rows in the hardware table, it must also be protected in\norder to avoid TOCTOU errors where multiple cores allocate the same\nrow.\n\nThis issue was detected in a situation where `mvpp2_set_rx_mode()` ran\nconcurrently on two CPUs. In this particular case the\nMVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the\nclassifier unit to drop all incoming unicast - indicated by the\n`rx_classifier_drops` counter.(CVE-2025-22060)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix NULL pointer in can_accept_new_subflow\n\nWhen testing valkey benchmark tool with MPTCP, the kernel panics in\n\u0026apos;mptcp_can_accept_new_subflow\u0026apos; because subflow_req-\u0026gt;msk is NULL.\n\nCall trace:\n\n mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)\n subflow_syn_recv_sock (./net/mptcp/subflow.c:854)\n tcp_check_req (./net/ipv4/tcp_minisocks.c:863)\n tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268)\n ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207)\n ip_local_deliver_finish (./net/ipv4/ip_input.c:234)\n ip_local_deliver (./net/ipv4/ip_input.c:254)\n ip_rcv_finish (./net/ipv4/ip_input.c:449)\n ...\n\nAccording to the debug log, the same req received two SYN-ACK in a very\nshort time, very likely because the client retransmits the syn ack due\nto multiple reasons.\n\nEven if the packets are transmitted with a relevant time interval, they\ncan be processed by the server on different CPUs concurrently). The\n\u0026apos;subflow_req-\u0026gt;msk\u0026apos; ownership is transferred to the subflow the first,\nand there will be a risk of a null pointer dereference here.\n\nThis patch fixes this issue by moving the \u0026apos;subflow_req-\u0026gt;msk\u0026apos; under the\n`own_req == true` conditional.\n\nNote that the !msk check in subflow_hmac_valid() can be dropped, because\nthe same check already exists under the own_req mpj branch where the\ncode has been moved to.(CVE-2025-23145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: hfcpci: Fix warning when deleting uninitialized timer\n\nWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads\nto the following splat:\n\n[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0\n[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0\n[ 250.218775] Modules linked in: hfcpci(-) mISDN_core\n[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)\n[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0\n[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d\n[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286\n[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95\n[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0\n[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39\n[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001\n[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8\n[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000\n[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0\n[ 250.236117] Call Trace:\n[ 250.236599] \u0026lt;TASK\u0026gt;\n[ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130\n[ 250.237920] debug_object_assert_init+0x1f6/0x310\n[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10\n[ 250.239658] ? __lock_acquire+0xdea/0x1c70\n[ 250.240369] __try_to_del_timer_sync+0x69/0x140\n[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10\n[ 250.242058] ? __timer_delete_sync+0xc6/0x120\n[ 250.242842] ? lock_acquire+0x30/0x80\n[ 250.243474] ? __timer_delete_sync+0xc6/0x120\n[ 250.244262] __timer_delete_sync+0x98/0x120\n[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci]\n[ 250.245704] __do_sys_delete_module+0x348/0x510\n[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10\n[ 250.247338] do_syscall_64+0xc1/0x360\n[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFix this by initializing hfc_tl timer with DEFINE_TIMER macro.\nAlso, use mod_timer instead of manual timeout update.(CVE-2025-39833)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd/pmc: Add support for Van Gogh SoC\n\nThe ROG Xbox Ally (non-X) SoC features a similar architecture to the\nSteam Deck. While the Steam Deck supports S3 (s2idle causes a crash),\nthis support was dropped by the Xbox Ally which only S0ix suspend.\n\nSince the handler is missing here, this causes the device to not suspend\nand the AMD GPU driver to crash while trying to resume afterwards due to\na power hang.(CVE-2025-68334)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: Move team device type change at the end of team_port_add\n\nAttempting to add a port device that is already up will expectedly fail,\nbut not before modifying the team device header_ops.\n\nIn the case of the syzbot reproducer the gre0 device is\nalready in state UP when it attempts to add it as a\nport device of team0, this fails but before that\nheader_ops-\u0026gt;create of team0 is changed from eth_header to ipgre_header\nin the call to team_dev_type_check_change.\n\nLater when we end up in ipgre_header() struct ip_tunnel* points to nonsense\nas the private data of the device still holds a struct team.\n\nExample sequence of iproute2 commands to reproduce the hang/BUG():\nip link add dev team0 type team\nip link add dev gre0 type gre\nip link set dev gre0 up\nip link set dev gre0 master team0\nip link set dev team0 up\nping -I team0 1.1.1.1\n\nMove team_dev_type_check_change down where all other checks have passed\nas it changes the dev type with no way to restore it in case\none of the checks that follow it fail.\n\nAlso make sure to preserve the origial mtu assignment:\n - If port_dev is not the same type as dev, dev takes mtu from port_dev\n - If port_dev is the same type as dev, port_dev takes mtu from dev\n\nThis is done by adding a conditional before the call to dev_set_mtu\nto prevent it from assigning port_dev-\u0026gt;mtu = dev-\u0026gt;mtu and instead\nletting team_dev_type_check_change assign dev-\u0026gt;mtu = port_dev-\u0026gt;mtu.\nThe conditional is needed because the patch moves the call to\nteam_dev_type_check_change past dev_set_mtu.\n\nTesting:\n - team device driver in-tree selftests\n - Add/remove various devices as slaves of team device\n - syzbot(CVE-2025-68340)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix: validate PHY address before use\n\nThe ASIX driver reads the PHY address from the USB device via\nasix_read_phy_addr(). A malicious or faulty device can return an\ninvalid address (\u0026gt;= PHY_MAX_ADDR), which causes a warning in\nmdiobus_get_phy():\n\n addr 207 out of range\n WARNING: drivers/net/phy/mdio_bus.c:76\n\nValidate the PHY address in asix_read_phy_addr() and remove the\nnow-redundant check in ax88172a.c.(CVE-2025-71094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_gre: make ip6gre_header() robust\n\nOver the years, syzbot found many ways to crash the kernel\nin ip6gre_header() [1].\n\nThis involves team or bonding drivers ability to dynamically\nchange their dev-\u0026gt;needed_headroom and/or dev-\u0026gt;hard_header_len\n\nIn this particular crash mld_newpack() allocated an skb\nwith a too small reserve/headroom, and by the time mld_sendpack()\nwas called, syzbot managed to attach an ip6gre device.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:213 !\n \u0026lt;TASK\u0026gt;\n skb_under_panic net/core/skbuff.c:223 [inline]\n skb_push+0xc3/0xe0 net/core/skbuff.c:2641\n ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371\n dev_hard_header include/linux/netdevice.h:3436 [inline]\n neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618\n neigh_output include/net/neighbour.h:556 [inline]\n ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136\n __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]\n ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220\n NF_HOOK_COND include/linux/netfilter.h:307 [inline]\n ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247\n NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318\n mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855\n mld_send_cr net/ipv6/mcast.c:2154 [inline]\n mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693(CVE-2025-71098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: add VLAN id validation before using\n\nCurrently, the VLAN id may be used without validation when\nreceive a VLAN configuration mailbox from VF. The length of\nvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause\nout-of-bounds memory access once the VLAN id is bigger than\nor equal to VLAN_N_VID.\n\nTherefore, VLAN id needs to be checked to ensure it is within\nthe range of VLAN_N_VID.(CVE-2025-71112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix string copying in parse_apply_sb_mount_options()\n\nstrscpy_pad() can\u0026apos;t be used to copy a non-NUL-term string into a NUL-term\nstring of possibly bigger size. Commit 0efc5990bca5 (\u0026quot;string.h: Introduce\nmemtostr() and memtostr_pad()\u0026quot;) provides additional information in that\nregard. So if this happens, the following warning is observed:\n\nstrnlen: detected buffer overflow: 65 byte read of buffer size 64\nWARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032\nModules linked in:\nCPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039\n strnlen include/linux/fortify-string.h:235 [inline]\n sized_strscpy include/linux/fortify-string.h:309 [inline]\n parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline]\n __ext4_fill_super fs/ext4/super.c:5261 [inline]\n ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706\n get_tree_bdev_flags+0x387/0x620 fs/super.c:1636\n vfs_get_tree+0x93/0x380 fs/super.c:1814\n do_new_mount fs/namespace.c:3553 [inline]\n path_mount+0x6ae/0x1f70 fs/namespace.c:3880\n do_mount fs/namespace.c:3893 [inline]\n __do_sys_mount fs/namespace.c:4103 [inline]\n __se_sys_mount fs/namespace.c:4080 [inline]\n __x64_sys_mount+0x280/0x300 fs/namespace.c:4080\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nSince userspace is expected to provide s_mount_opts field to be at most 63\ncharacters long with the ending byte being NUL-term, use a 64-byte buffer\nwhich matches the size of s_mount_opts, so that strscpy_pad() does its job\nproperly. Return with error if the user still managed to provide a\nnon-NUL-term string here.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-71123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer\n\nInitialize the eb.vma array with values of 0 when the eb structure is\nfirst set up. In particular, this sets the eb-\u0026gt;vma[i].vma pointers to\nNULL, simplifying cleanup and getting rid of the bug described below.\n\nDuring the execution of eb_lookup_vmas(), the eb-\u0026gt;vma array is\nsuccessively filled up with struct eb_vma objects. This process includes\ncalling eb_add_vma(), which might fail; however, even in the event of\nfailure, eb-\u0026gt;vma[i].vma is set for the currently processed buffer.\n\nIf eb_add_vma() fails, eb_lookup_vmas() returns with an error, which\nprompts a call to eb_release_vmas() to clean up the mess. Since\neb_lookup_vmas() might fail during processing any (possibly not first)\nbuffer, eb_release_vmas() checks whether a buffer\u0026apos;s vma is NULL to know\nat what point did the lookup function fail.\n\nIn eb_lookup_vmas(), eb-\u0026gt;vma[i].vma is set to NULL if either the helper\nfunction eb_lookup_vma() or eb_validate_vma() fails. eb-\u0026gt;vma[i+1].vma is\nset to NULL in case i915_gem_object_userptr_submit_init() fails; the\ncurrent one needs to be cleaned up by eb_release_vmas() at this point,\nso the next one is set. If eb_add_vma() fails, neither the current nor\nthe next vma is set to NULL, which is a source of a NULL deref bug\ndescribed in the issue linked in the Closes tag.\n\nWhen entering eb_lookup_vmas(), the vma pointers are set to the slab\npoison value, instead of NULL. This doesn\u0026apos;t matter for the actual\nlookup, since it gets overwritten anyway, however the eb_release_vmas()\nfunction only recognizes NULL as the stopping value, hence the pointers\nare being set to NULL as they go in case of intermediate failure. This\npatch changes the approach to filling them all with NULL at the start\ninstead, rather than handling that manually during failure.\n\n(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)(CVE-2025-71130)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc91x: fix broken irq-context in PREEMPT_RT\n\nWhen smc91x.c is built with PREEMPT_RT, the following splat occurs\nin FVP_RevC:\n\n[ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000\n[ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106]\n[ 13.062137] preempt=0x00000000 lock=0-\u0026gt;0 RCU=0-\u0026gt;1 workfn=mld_ifc_work\n[ 13.062266] C\n** replaying previous printk message **\n[ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}\n[ 13.062353] Hardware name: , BIOS\n[ 13.062382] Workqueue: mld mld_ifc_work\n[ 13.062469] Call trace:\n[ 13.062494] show_stack+0x24/0x40 (C)\n[ 13.062602] __dump_stack+0x28/0x48\n[ 13.062710] dump_stack_lvl+0x7c/0xb0\n[ 13.062818] dump_stack+0x18/0x34\n[ 13.062926] process_scheduled_works+0x294/0x450\n[ 13.063043] worker_thread+0x260/0x3d8\n[ 13.063124] kthread+0x1c4/0x228\n[ 13.063235] ret_from_fork+0x10/0x20\n\nThis happens because smc_special_trylock() disables IRQs even on PREEMPT_RT,\nbut smc_special_unlock() does not restore IRQs on PREEMPT_RT.\nThe reason is that smc_special_unlock() calls spin_unlock_irqrestore(),\nand rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke\nrcu_read_unlock() through __local_bh_enable_ip() when current-\u0026gt;softirq_disable_cnt becomes zero.\n\nTo address this issue, replace smc_special_trylock() with spin_trylock_irqsave().(CVE-2025-71132)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: avoid chain re-validation if possible\n\nHamza Mahfooz reports cpu soft lock-ups in\nnft_chain_validate():\n\n watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]\n[..]\n RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]\n[..]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_immediate_validate+0x36/0x50 [nf_tables]\n nft_chain_validate+0xc9/0x110 [nf_tables]\n nft_table_validate+0x6b/0xb0 [nf_tables]\n nf_tables_validate+0x8b/0xa0 [nf_tables]\n nf_tables_commit+0x1df/0x1eb0 [nf_tables]\n[..]\n\nCurrently nf_tables will traverse the entire table (chain graph), starting\nfrom the entry points (base chains), exploring all possible paths\n(chain jumps). But there are cases where we could avoid revalidation.\n\nConsider:\n1 input -\u0026gt; j2 -\u0026gt; j3\n2 input -\u0026gt; j2 -\u0026gt; j3\n3 input -\u0026gt; j1 -\u0026gt; j2 -\u0026gt; j3\n\nThen the second rule does not need to revalidate j2, and, by extension j3,\nbecause this was already checked during validation of the first rule.\nWe need to validate it only for rule 3.\n\nThis is needed because chain loop detection also ensures we do not exceed\nthe jump stack: Just because we know that j2 is cycle free, its last jump\nmight now exceed the allowed stack size. We also need to update all\nreachable chains with the new largest observed call depth.\n\nCare has to be taken to revalidate even if the chain depth won\u0026apos;t be an\nissue: chain validation also ensures that expressions are not called from\ninvalid base chains. For example, the masquerade expression can only be\ncalled from NAT postrouting base chains.\n\nTherefore we also need to keep record of the base chain context (type,\nhooknum) and revalidate if the chain becomes reachable from a different\nhook location.(CVE-2025-71160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock in wait_current_trans() due to ignored transaction type\n\nWhen wait_current_trans() is called during start_transaction(), it\ncurrently waits for a blocked transaction without considering whether\nthe given transaction type actually needs to wait for that particular\ntransaction state. The btrfs_blocked_trans_types[] array already defines\nwhich transaction types should wait for which transaction states, but\nthis check was missing in wait_current_trans().\n\nThis can lead to a deadlock scenario involving two transactions and\npending ordered extents:\n\n 1. Transaction A is in TRANS_STATE_COMMIT_DOING state\n\n 2. A worker processing an ordered extent calls start_transaction()\n with TRANS_JOIN\n\n 3. join_transaction() returns -EBUSY because Transaction A is in\n TRANS_STATE_COMMIT_DOING\n\n 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes\n\n 5. A new Transaction B is created (TRANS_STATE_RUNNING)\n\n 6. The ordered extent from step 2 is added to Transaction B\u0026apos;s\n pending ordered extents\n\n 7. Transaction B immediately starts commit by another task and\n enters TRANS_STATE_COMMIT_START\n\n 8. The worker finally reaches wait_current_trans(), sees Transaction B\n in TRANS_STATE_COMMIT_START (a blocked state), and waits\n unconditionally\n\n 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START\n according to btrfs_blocked_trans_types[]\n\n 10. Transaction B is waiting for pending ordered extents to complete\n\n 11. Deadlock: Transaction B waits for ordered extent, ordered extent\n waits for Transaction B\n\nThis can be illustrated by the following call stacks:\n CPU0 CPU1\n btrfs_finish_ordered_io()\n start_transaction(TRANS_JOIN)\n join_transaction()\n # -EBUSY (Transaction A is\n # TRANS_STATE_COMMIT_DOING)\n # Transaction A completes\n # Transaction B created\n # ordered extent added to\n # Transaction B\u0026apos;s pending list\n btrfs_commit_transaction()\n # Transaction B enters\n # TRANS_STATE_COMMIT_START\n # waiting for pending ordered\n # extents\n wait_current_trans()\n # waits for Transaction B\n # (should not wait!)\n\nTask bstore_kv_sync in btrfs_commit_transaction waiting for ordered\nextents:\n\n __schedule+0x2e7/0x8a0\n schedule+0x64/0xe0\n btrfs_commit_transaction+0xbf7/0xda0 [btrfs]\n btrfs_sync_file+0x342/0x4d0 [btrfs]\n __x64_sys_fdatasync+0x4b/0x80\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nTask kworker in wait_current_trans waiting for transaction commit:\n\n Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs]\n __schedule+0x2e7/0x8a0\n schedule+0x64/0xe0\n wait_current_trans+0xb0/0x110 [btrfs]\n start_transaction+0x346/0x5b0 [btrfs]\n btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]\n btrfs_work_helper+0xe8/0x350 [btrfs]\n process_one_work+0x1d3/0x3c0\n worker_thread+0x4d/0x3e0\n kthread+0x12d/0x150\n ret_from_fork+0x1f/0x30\n\nFix this by passing the transaction type to wait_current_trans() and\nchecking btrfs_blocked_trans_types[cur_trans-\u0026gt;state] against the given\ntype before deciding to wait. This ensures that transaction types which\nare allowed to join during certain blocked states will not unnecessarily\nwait and cause deadlocks.(CVE-2025-71194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/sva: invalidate stale IOTLB entries for kernel address space\n\nIntroduce a new IOMMU interface to flush IOTLB paging cache entries for\nthe CPU kernel address space. This interface is invoked from the x86\narchitecture code that manages combined user and kernel page tables,\nspecifically before any kernel page table page is freed and reused.\n\nThis addresses the main issue with vfree() which is a common occurrence\nand can be triggered by unprivileged users. While this resolves the\nprimary problem, it doesn\u0026apos;t address some extremely rare case related to\nmemory unplug of memory that was present as reserved memory at boot, which\ncannot be triggered by unprivileged users. The discussion can be found at\nthe link below.\n\nEnable SVA on x86 architecture since the IOMMU can now receive\nnotification to flush the paging cache before freeing the CPU kernel page\ntable pages.(CVE-2025-71202)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naudit: add fchmodat2() to change attributes class\n\nfchmodat2(), introduced in version 6.6 is currently not in the change\nattribute class of audit. Calling fchmodat2() to change a file\nattribute in the same fashion than chmod() or fchmodat() will bypass\naudit rules such as:\n\n-w /tmp/test -p rwa -k test_rwa\n\nThe current patch adds fchmodat2() to the change attributes class.(CVE-2025-71239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix possible UAF in macvlan_forward_source()\n\nAdd RCU protection on (struct macvlan_source_entry)-\u0026gt;vlan.\n\nWhenever macvlan_hash_del_source() is called, we must clear\nentry-\u0026gt;vlan pointer before RCU grace period starts.\n\nThis allows macvlan_forward_source() to skip over\nentries queued for freeing.\n\nNote that macvlan_dev are already RCU protected, as they\nare embedded in a standard netdev (netdev_priv(ndev)).\n\nhttps: //lore.kernel.org/netdev/(CVE-2026-23001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuacce: ensure safe queue release with state management\n\nDirectly calling `put_queue` carries risks since it cannot\nguarantee that resources of `uacce_queue` have been fully released\nbeforehand. So adding a `stop_queue` operation for the\nUACCE_CMD_PUT_Q command and leaving the `put_queue` operation to\nthe final resource release ensures safety.\n\nQueue states are defined as follows:\n- UACCE_Q_ZOMBIE: Initial state\n- UACCE_Q_INIT: After opening `uacce`\n- UACCE_Q_STARTED: After `start` is issued via `ioctl`\n\nWhen executing `poweroff -f` in virt while accelerator are still\nworking, `uacce_fops_release` and `uacce_remove` may execute\nconcurrently. This can cause `uacce_put_queue` within\n`uacce_fops_release` to access a NULL `ops` pointer. Therefore, add\nstate checks to prevent accessing freed pointers.(CVE-2026-23063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Enforce that teql can only be used as root qdisc\n\nDesign intent of teql is that it is only supposed to be used as root qdisc.\nWe need to check for that constraint.\n\nAlthough not important, I will describe the scenario that unearthed this\nissue for the curious.\n\nGangMin Kim \u0026lt;(CVE-2026-23074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: signal: Fix restoration of SVE context\n\nWhen SME is supported, Restoring SVE signal context can go wrong in a\nfew ways, including placing the task into an invalid state where the\nkernel may read from out-of-bounds memory (and may potentially take a\nfatal fault) and/or may kill the task with a SIGKILL.\n\n(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into\n an invalid state where SVCR.SM is set (and sve_state is non-NULL)\n but TIF_SME is clear, consequently resuting in out-of-bounds memory\n reads and/or killing the task with SIGKILL.\n\n This can only occur in unusual (but legitimate) cases where the SVE\n signal context has either been modified by userspace or was saved in\n the context of another task (e.g. as with CRIU), as otherwise the\n presence of an SVE signal context with SVE_SIG_FLAG_SM implies that\n TIF_SME is already set.\n\n While in this state, task_fpsimd_load() will NOT configure SMCR_ELx\n (leaving some arbitrary value configured in hardware) before\n restoring SVCR and attempting to restore the streaming mode SVE\n registers from memory via sve_load_state(). As the value of\n SMCR_ELx.LEN may be larger than the task\u0026apos;s streaming SVE vector\n length, this may read memory outside of the task\u0026apos;s allocated\n sve_state, reading unrelated data and/or triggering a fault.\n\n While this can result in secrets being loaded into streaming SVE\n registers, these values are never exposed. As TIF_SME is clear,\n fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0\n accesses to streaming mode SVE registers, so these cannot be\n accessed directly at EL0. As fpsimd_save_user_state() verifies the\n live vector length before saving (S)SVE state to memory, no secret\n values can be saved back to memory (and hence cannot be observed via\n ptrace, signals, etc).\n\n When the live vector length doesn\u0026apos;t match the expected vector length\n for the task, fpsimd_save_user_state() will send a fatal SIGKILL\n signal to the task. Hence the task may be killed after executing\n userspace for some period of time.\n\n(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the\n task\u0026apos;s SVCR.SM. If SVCR.SM was set prior to restoring the context,\n then the task will be left in streaming mode unexpectedly, and some\n register state will be combined inconsistently, though the task will\n be left in legitimate state from the kernel\u0026apos;s PoV.\n\n This can only occur in unusual (but legitimate) cases where ptrace\n has been used to set SVCR.SM after entry to the sigreturn syscall,\n as syscall entry clears SVCR.SM.\n\n In these cases, the the provided SVE register data will be loaded\n into the task\u0026apos;s sve_state using the non-streaming SVE vector length\n and the FPSIMD registers will be merged into this using the\n streaming SVE vector length.\n\nFix (1) by setting TIF_SME when setting SVCR.SM. This also requires\nensuring that the task\u0026apos;s sme_state has been allocated, but as this could\ncontain live ZA state, it should not be zeroed. Fix (2) by clearing\nSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.\n\nFor consistency, I\u0026apos;ve pulled the manipulation of SVCR, TIF_SVE, TIF_SME,\nand fp_type earlier, immediately after the allocation of\nsve_state/sme_state, before the restore of the actual register state.\nThis makes it easier to ensure that these are always modified\nconsistently, even if a fault is taken while reading the register data\nfrom the signal context. I do not expect any software to depend on the\nexact state restored when a fault is taken while reading the context.(CVE-2026-23102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem, swap: fix race of truncate and swap entry split\n\nThe helper for shmem swap freeing is not handling the order of swap\nentries correctly. It uses xa_cmpxchg_irq to erase the swap entry, but it\ngets the entry order before that using xa_get_order without lock\nprotection, and it may get an outdated order value if the entry is split\nor changed in other ways after the xa_get_order and before the\nxa_cmpxchg_irq.\n\nAnd besides, the order could grow and be larger than expected, and cause\ntruncation to erase data beyond the end border. For example, if the\ntarget entry and following entries are swapped in or freed, then a large\nfolio was added in place and swapped out, using the same entry, the\nxa_cmpxchg_irq will still succeed, it\u0026apos;s very unlikely to happen though.\n\nTo fix that, open code the Xarray cmpxchg and put the order retrieval and\nvalue checking in the same critical section. Also, ensure the order won\u0026apos;t\nexceed the end border, skip it if the entry goes across the border.\n\nSkipping large swap entries crosses the end border is safe here. Shmem\ntruncate iterates the range twice, in the first iteration,\nfind_lock_entries already filtered such entries, and shmem will swapin the\nentries that cross the end border and partially truncate the folio (split\nthe folio or at least zero part of it). So in the second loop here, if we\nsee a swap entry that crosses the end order, it must at least have its\ncontent erased already.\n\nI observed random swapoff hangs and kernel panics when stress testing\nZSWAP with shmem. After applying this patch, all problems are gone.(CVE-2026-23161)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umad: Reject negative data_len in ib_umad_write\n\nib_umad_write computes data_len from user-controlled count and the\nMAD header sizes. With a mismatched user MAD header size and RMPP\nheader length, data_len can become negative and reach ib_create_send_mad().\nThis can make the padding calculation exceed the segment size and trigger\nan out-of-bounds memset in alloc_send_rmpp_list().\n\nAdd an explicit check to reject negative data_len before creating the\nsend buffer.\n\nKASAN splat:\n[ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0\n[ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102\n[ 211.365867] ib_create_send_mad+0xa01/0x11b0\n[ 211.365887] ib_umad_write+0x853/0x1c80(CVE-2026-23243)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix memory allocation in nvme_pr_read_keys()\n\nnvme_pr_read_keys() takes num_keys from userspace and uses it to\ncalculate the allocation size for rse via struct_size(). The upper\nlimit is PR_KEYS_MAX (64K).\n\nA malicious or buggy userspace can pass a large num_keys value that\nresults in a 4MB allocation attempt at most, causing a warning in\nthe page allocator when the order exceeds MAX_PAGE_ORDER.\n\nTo fix this, use kvzalloc() instead of kzalloc().\n\nThis bug has the same reasoning and fix with the patch below:\nhttps://lore.kernel.org/linux-block/(CVE-2026-23244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: unconditionally bump set-\u0026gt;nelems before insertion\n\nIn case that the set is full, a new element gets published then removed\nwithout waiting for the RCU grace period, while RCU reader can be\nwalking over it already.\n\nTo address this issue, add the element transaction even if set is full,\nbut toggle the set_full flag to report -ENFILE so the abort path safely\nunwinds the set to its previous state.\n\nAs for element updates, decrement set-\u0026gt;nelems to restore it.\n\nA simpler fix is to call synchronize_rcu() in the error path.\nHowever, with a large batch adding elements to already maxed-out set,\nthis could cause noticeable slowdown of such batches.(CVE-2026-23272)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: kaweth: validate USB endpoints\n\nThe kaweth driver should validate that the device it is probing has the\nproper number and types of USB endpoints it is expecting before it binds\nto it. If a malicious device were to not have the same urbs the driver\nwill crash later on when it blindly accesses these endpoints.(CVE-2026-23312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs\n\nWhen shrinking the number of real tx queues,\nnetif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush\nqdiscs for queues which will no longer be used.\n\nqdisc_reset_all_tx_gt() currently serializes qdisc_reset() with\nqdisc_lock(). However, for lockless qdiscs, the dequeue path is\nserialized by qdisc_run_begin/end() using qdisc-\u0026gt;seqlock instead, so\nqdisc_reset() can run concurrently with __qdisc_run() and free skbs\nwhile they are still being dequeued, leading to UAF.\n\nThis can easily be reproduced on e.g. virtio-net by imposing heavy\ntraffic while frequently changing the number of queue pairs:\n\n iperf3 -ub0 -c $peer -t 0 \u0026amp;\n while :; do\n ethtool -L eth0 combined 1\n ethtool -L eth0 combined 2\n done\n\nWith KASAN enabled, this leads to reports like:\n\n BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ...\n __qdisc_run+0x133f/0x1760\n __dev_queue_xmit+0x248f/0x3550\n ip_finish_output2+0xa42/0x2110\n ip_output+0x1a7/0x410\n ip_send_skb+0x2e6/0x480\n udp_send_skb+0xb0a/0x1590\n udp_sendmsg+0x13c9/0x1fc0\n ...\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 1270 on cpu 5 at 44.558414s:\n ...\n alloc_skb_with_frags+0x84/0x7c0\n sock_alloc_send_pskb+0x69a/0x830\n __ip_append_data+0x1b86/0x48c0\n ip_make_skb+0x1e8/0x2b0\n udp_sendmsg+0x13a6/0x1fc0\n ...\n\n Freed by task 1306 on cpu 3 at 44.558445s:\n ...\n kmem_cache_free+0x117/0x5e0\n pfifo_fast_reset+0x14d/0x580\n qdisc_reset+0x9e/0x5f0\n netif_set_real_num_tx_queues+0x303/0x840\n virtnet_set_channels+0x1bf/0x260 [virtio_net]\n ethnl_set_channels+0x684/0xae0\n ethnl_default_set_doit+0x31a/0x890\n ...\n\nSerialize qdisc_reset_all_tx_gt() against the lockless dequeue path by\ntaking qdisc-\u0026gt;seqlock for TCQ_F_NOLOCK qdiscs, matching the\nserialization model already used by dev_reset_queue().\n\nAdditionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state\nreflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check\n\ncdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE\nentries fit within the skb. The first check correctly accounts for\nndpoffset:\n\n if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) \u0026gt; skb_in-\u0026gt;len)\n\nbut the second check omits it:\n\n if ((sizeof(struct usb_cdc_ncm_ndp16) +\n ret * (sizeof(struct usb_cdc_ncm_dpe16))) \u0026gt; skb_in-\u0026gt;len)\n\nThis validates the DPE array size against the total skb length as if\nthe NDP were at offset 0, rather than at ndpoffset. When the NDP is\nplaced near the end of the NTB (large wNdpIndex), the DPE entries can\nextend past the skb data buffer even though the check passes.\ncdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating\nthe DPE array.\n\nAdd ndpoffset to the nframes bounds check and use struct_size_t() to\nexpress the NDP-plus-DPE-array size more clearly.(CVE-2026-23448)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2026-23473)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix krb5 mount with username option\n\nCustomer reported that some of their krb5 mounts were failing against\na single server as the client was trying to mount the shares with\nwrong credentials. It turned out the client was reusing SMB session\nfrom first mount to try mounting the other shares, even though a\ndifferent username= option had been specified to the other mounts.\n\nBy using username mount option along with sec=krb5 to search for\nprincipals from keytab is supported by cifs.upcall(8) since\ncifs-utils-4.8. So fix this by matching username mount option in\nmatch_session() even with Kerberos.\n\nFor example, the second mount below should fail with -ENOKEY as there\nis no \u0026apos;foobar\u0026apos; principal in keytab (/etc/krb5.keytab). The client\nends up reusing SMB session from first mount to perform the second\none, which is wrong.\n\n```\n$ ktutil\nktutil: add_entry -password -p testuser -k 1 -e aes256-cts\nPassword for (CVE-2026-31392)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: fix incorrect pte restoration for lazyfree folios\n\nWe batch unmap anonymous lazyfree folios by folio_unmap_pte_batch. If the\nbatch has a mix of writable and non-writable bits, we may end up setting\nthe entire batch writable. Fix this by respecting writable bit during\nbatching.\n\nAlthough on a successful unmap of a lazyfree folio, the soft-dirty bit is\nlost, preserve it on pte restoration by respecting the bit during\nbatching, to make the fix consistent w.r.t both writable bit and\nsoft-dirty bit.\n\nI was able to write the below reproducer and crash the kernel. \nExplanation of reproducer (set 64K mTHP to always):\n\nFault in a 64K large folio. Split the VMA at mid-point with\nMADV_DONTFORK. fork() - parent points to the folio with 8 writable ptes\nand 8 non-writable ptes. Merge the VMAs with MADV_DOFORK so that\nfolio_unmap_pte_batch() can determine all the 16 ptes as a batch. Do\nMADV_FREE on the range to mark the folio as lazyfree. Write to the memory\nto dirty the pte, eventually rmap will dirty the folio. Then trigger\nreclaim, we will hit the pte restoration path, and the kernel will crash\nwith the trace given below.\n\nThe BUG happens at:\n\n\tBUG_ON(atomic_inc_return(\u0026amp;ptc-\u0026gt;anon_map_count) \u0026gt; 1 \u0026amp;\u0026amp; rw);\n\nThe code path is asking for anonymous page to be mapped writable into the\npagetable. The BUG_ON() firing implies that such a writable page has been\nmapped into the pagetables of more than one process, which breaks\nanonymous memory/CoW semantics.\n\n[ 21.134473] kernel BUG at mm/page_table_check.c:118!\n[ 21.134497] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 21.135917] Modules linked in:\n[ 21.136085] CPU: 1 UID: 0 PID: 1735 Comm: dup-lazyfree Not tainted 7.0.0-rc1-00116-g018018a17770 #1028 PREEMPT\n[ 21.136858] Hardware name: linux,dummy-virt (DT)\n[ 21.137019] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 21.137308] pc : page_table_check_set+0x28c/0x2a8\n[ 21.137607] lr : page_table_check_set+0x134/0x2a8\n[ 21.137885] sp : ffff80008a3b3340\n[ 21.138124] x29: ffff80008a3b3340 x28: fffffdffc3d14400 x27: ffffd1a55e03d000\n[ 21.138623] x26: 0040000000000040 x25: ffffd1a55f7dd000 x24: 0000000000000001\n[ 21.139045] x23: 0000000000000001 x22: 0000000000000001 x21: ffffd1a55f217f30\n[ 21.139629] x20: 0000000000134521 x19: 0000000000134519 x18: 005c43e000040000\n[ 21.140027] x17: 0001400000000000 x16: 0001700000000000 x15: 000000000000ffff\n[ 21.140578] x14: 000000000000000c x13: 005c006000000000 x12: 0000000000000020\n[ 21.140828] x11: 0000000000000000 x10: 005c000000000000 x9 : ffffd1a55c079ee0\n[ 21.141077] x8 : 0000000000000001 x7 : 005c03e000040000 x6 : 000000004000ffff\n[ 21.141490] x5 : ffff00017fffce00 x4 : 0000000000000001 x3 : 0000000000000002\n[ 21.141741] x2 : 0000000000134510 x1 : 0000000000000000 x0 : ffff0000c08228c0\n[ 21.141991] Call trace:\n[ 21.142093] page_table_check_set+0x28c/0x2a8 (P)\n[ 21.142265] __page_table_check_ptes_set+0x144/0x1e8\n[ 21.142441] __set_ptes_anysz.constprop.0+0x160/0x1a8\n[ 21.142766] contpte_set_ptes+0xe8/0x140\n[ 21.142907] try_to_unmap_one+0x10c4/0x10d0\n[ 21.143177] rmap_walk_anon+0x100/0x250\n[ 21.143315] try_to_unmap+0xa0/0xc8\n[ 21.143441] shrink_folio_list+0x59c/0x18a8\n[ 21.143759] shrink_lruvec+0x664/0xbf0\n[ 21.144043] shrink_node+0x218/0x878\n[ 21.144285] __node_reclaim.constprop.0+0x98/0x338\n[ 21.144763] user_proactive_reclaim+0x2a4/0x340\n[ 21.145056] reclaim_store+0x3c/0x60\n[ 21.145216] dev_attr_store+0x20/0x40\n[ 21.145585] sysfs_kf_write+0x84/0xa8\n[ 21.145835] kernfs_fop_write_iter+0x130/0x1c8\n[ 21.145994] vfs_write+0x2b8/0x368\n[ 21.146119] ksys_write+0x70/0x110\n[ 21.146240] __arm64_sys_write+0x24/0x38\n[ 21.146380] invoke_syscall+0x50/0x120\n[ 21.146513] el0_svc_common.constprop.0+0x48/0xf8\n[ 21.146679] do_el0_svc+0x28/0x40\n[ 21.146798] el0_svc+0x34/0x110\n[ 21.146926] el0t\n---truncated---(CVE-2026-31398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_fw: fix NULL pointer dereference on shared blocks\n\nThe old-method path in fw_classify() calls tcf_block_q() and\ndereferences q-\u0026gt;handle. Shared blocks leave block-\u0026gt;q NULL, causing a\nNULL deref when an empty cls_fw filter is attached to a shared block\nand a packet with a nonzero major skb mark is classified.\n\nReject the configuration in fw_change() when the old method (no\nTCA_OPTIONS) is used on a shared block, since fw_classify()\u0026apos;s\nold-method path needs block-\u0026gt;q which is NULL for shared blocks.\n\nThe fixed null-ptr-deref calling stack:\n KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]\n RIP: 0010:fw_classify (net/sched/cls_fw.c:81)\n Call Trace:\n tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)\n tc_run (net/core/dev.c:4401)\n __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)(CVE-2026-31421)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_flow: fix NULL pointer dereference on shared blocks\n\nflow_change() calls tcf_block_q() and dereferences q-\u0026gt;handle to derive\na default baseclass. Shared blocks leave block-\u0026gt;q NULL, causing a NULL\nderef when a flow filter without a fully qualified baseclass is created\non a shared block.\n\nCheck tcf_block_shared() before accessing block-\u0026gt;q and return -EINVAL\nfor shared blocks. This avoids the null-deref shown below:\n\n=======================================================================\nKASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]\nRIP: 0010:flow_change (net/sched/cls_flow.c:508)\nCall Trace:\n tc_new_tfilter (net/sched/cls_api.c:2432)\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)\n [...]\n=======================================================================(CVE-2026-31422)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skb: fix cross-cache free of KFENCE-allocated skb head\n\nSKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2\nvalue (e.g. 704 on x86_64) to avoid collisions with generic kmalloc\nbucket sizes. This ensures that skb_kfree_head() can reliably use\nskb_end_offset to distinguish skb heads allocated from\nskb_small_head_cache vs. generic kmalloc caches.\n\nHowever, when KFENCE is enabled, kfence_ksize() returns the exact\nrequested allocation size instead of the slab bucket size. If a caller\n(e.g. bpf_test_init) allocates skb head data via kzalloc() and the\nrequested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then\nslab_build_skb() -\u0026gt; ksize() returns that exact value. After subtracting\nskb_shared_info overhead, skb_end_offset ends up matching\nSKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free\nthe object to skb_small_head_cache instead of back to the original\nkmalloc cache, resulting in a slab cross-cache free:\n\n kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected\n skbuff_small_head but got kmalloc-1k\n\nFix this by always calling kfree(head) in skb_kfree_head(). This keeps\nthe free path generic and avoids allocator-specific misclassification\nfor KFENCE objects.(CVE-2026-31429)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nX.509: Fix out-of-bounds access when parsing extensions\n\nLeo reports an out-of-bounds access when parsing a certificate with\nempty Basic Constraints or Key Usage extension because the first byte of\nthe extension is read before checking its length. Fix it.\n\nThe bug can be triggered by an unprivileged user by submitting a\nspecially crafted certificate to the kernel through the keyrings(7) API.\nLeo has demonstrated this with a proof-of-concept program responsibly\ndisclosed off-list.(CVE-2026-31430)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix memory leak when a wq is reset\n\nidxd_wq_disable_cleanup() which is called from the reset path for a\nworkqueue, sets the wq type to NONE, which for other parts of the\ndriver mean that the wq is empty (all its resources were released).\n\nOnly set the wq type to NONE after its resources are released.(CVE-2026-31441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix possible invalid memory access after FLR\n\nIn the case that the first Function Level Reset (FLR) concludes\ncorrectly, but in the second FLR the scratch area for the saved\nconfiguration cannot be allocated, it\u0026apos;s possible for a invalid memory\naccess to happen.\n\nAlways set the deallocated scratch area to NULL after FLR completes.(CVE-2026-31442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix use-after-free in update_super_work when racing with umount\n\nCommit b98535d09179 (\u0026quot;ext4: fix bug_on in start_this_handle during umount\nfilesystem\u0026quot;) moved ext4_unregister_sysfs() before flushing s_sb_upd_work\nto prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups\nreads during unmount. However, this introduced a use-after-free because\nupdate_super_work calls ext4_notify_error_sysfs() -\u0026gt; sysfs_notify() which\naccesses the kobject\u0026apos;s kernfs_node after it has been freed by kobject_del()\nin ext4_unregister_sysfs():\n\n update_super_work ext4_put_super\n ----------------- --------------\n ext4_unregister_sysfs(sb)\n kobject_del(\u0026amp;sbi-\u0026gt;s_kobj)\n __kobject_del()\n sysfs_remove_dir()\n kobj-\u0026gt;sd = NULL\n sysfs_put(sd)\n kernfs_put() // RCU free\n ext4_notify_error_sysfs(sbi)\n sysfs_notify(\u0026amp;sbi-\u0026gt;s_kobj)\n kn = kobj-\u0026gt;sd // stale pointer\n kernfs_get(kn) // UAF on freed kernfs_node\n ext4_journal_destroy()\n flush_work(\u0026amp;sbi-\u0026gt;s_sb_upd_work)\n\nInstead of reordering the teardown sequence, fix this by making\next4_notify_error_sysfs() detect that sysfs has already been torn down\nby checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call\nin that case. A dedicated mutex (s_error_notify_mutex) serializes\next4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()\nto prevent TOCTOU races where the kobject could be deleted between the\nstate_in_sysfs check and the sysfs_notify() call.(CVE-2026-31446)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: validate p_idx bounds in ext4_ext_correct_indexes\n\next4_ext_correct_indexes() walks up the extent tree correcting\nindex entries when the first extent in a leaf is modified. Before\naccessing path[k].p_idx-\u0026gt;ei_block, there is no validation that\np_idx falls within the valid range of index entries for that\nlevel.\n\nIf the on-disk extent header contains a corrupted or crafted\neh_entries value, p_idx can point past the end of the allocated\nbuffer, causing a slab-out-of-bounds read.\n\nFix this by validating path[k].p_idx against EXT_LAST_INDEX() at\nboth access sites: before the while loop and inside it. Return\n-EFSCORRUPTED if the index pointer is out of range, consistent\nwith how other bounds violations are handled in the ext4 extent\ntree code.(CVE-2026-31449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: publish jinode after initialization\n\next4_inode_attach_jinode() publishes ei-\u0026gt;jinode to concurrent users.\nIt used to set ei-\u0026gt;jinode before jbd2_journal_init_jbd_inode(),\nallowing a reader to observe a non-NULL jinode with i_vfs_inode\nstill unset.\n\nThe fast commit flush path can then pass this jinode to\njbd2_wait_inode_data(), which dereferences i_vfs_inode-\u0026gt;i_mapping and\nmay crash.\n\nBelow is the crash I observe:\n```\nBUG: unable to handle page fault for address: 000000010beb47f4\nPGD 110e51067 P4D 110e51067 PUD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014\nRIP: 0010:xas_find_marked+0x3d/0x2e0\nCode: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f \u0026lt;49\u0026gt; 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02\nRSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246\nRAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003\nRDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10\nRBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec\nR10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000\nR13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88\nFS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n\u0026lt;TASK\u0026gt;\nfilemap_get_folios_tag+0x87/0x2a0\n__filemap_fdatawait_range+0x5f/0xd0\n? srso_alias_return_thunk+0x5/0xfbef5\n? __schedule+0x3e7/0x10c0\n? srso_alias_return_thunk+0x5/0xfbef5\n? srso_alias_return_thunk+0x5/0xfbef5\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\n? cap_safe_nice+0x37/0x70\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\nfilemap_fdatawait_range_keep_errors+0x12/0x40\next4_fc_commit+0x697/0x8b0\n? ext4_file_write_iter+0x64b/0x950\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\n? vfs_write+0x356/0x480\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\next4_sync_file+0xf7/0x370\ndo_fsync+0x3b/0x80\n? syscall_trace_enter+0x108/0x1d0\n__x64_sys_fdatasync+0x16/0x20\ndo_syscall_64+0x62/0x2c0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n...\n```\n\nFix this by initializing the jbd2_inode first.\nUse smp_wmb() and WRITE_ONCE() to publish ei-\u0026gt;jinode after\ninitialization. Readers use READ_ONCE() to fetch the pointer.(CVE-2026-31450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: replace BUG_ON with proper error handling in ext4_read_inline_folio\n\nReplace BUG_ON() with proper error handling when inline data size\nexceeds PAGE_SIZE. This prevents kernel panic and allows the system to\ncontinue running while properly reporting the filesystem corruption.\n\nThe error is logged via ext4_error_inode(), the buffer head is released\nto prevent memory leak, and -EFSCORRUPTED is returned to indicate\nfilesystem corruption.(CVE-2026-31451)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: convert inline data to extents when truncate exceeds inline size\n\nAdd a check in ext4_setattr() to convert files from inline data storage\nto extent-based storage when truncate() grows the file size beyond the\ninline capacity. This prevents the filesystem from entering an\ninconsistent state where the inline data flag is set but the file size\nexceeds what can be stored inline.\n\nWithout this fix, the following sequence causes a kernel BUG_ON():\n\n1. Mount filesystem with inode that has inline flag set and small size\n2. truncate(file, 50MB) - grows size but inline flag remains set\n3. sendfile() attempts to write data\n4. ext4_write_inline_data() hits BUG_ON(write_size \u0026gt; inline_capacity)\n\nThe crash occurs because ext4_write_inline_data() expects inline storage\nto accommodate the write, but the actual inline capacity (~60 bytes for\ni_block + ~96 bytes for xattrs) is far smaller than the file size and\nwrite request.\n\nThe fix checks if the new size from setattr exceeds the inode\u0026apos;s actual\ninline capacity (EXT4_I(inode)-\u0026gt;i_inline_size) and converts the file to\nextent-based storage before proceeding with the size change.\n\nThis addresses the root cause by ensuring the inline data flag and file\nsize remain consistent during truncate operations.(CVE-2026-31452)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: add GFP_NOIO in the bio completion if needed\n\nThe bio completion path in the process context (e.g. dm-verity)\nwill directly call into decompression rather than trigger another\nworkqueue context for minimal scheduling latencies, which can\nthen call vm_map_ram() with GFP_KERNEL.\n\nDue to insufficient memory, vm_map_ram() may generate memory\nswapping I/O, which can cause submit_bio_wait to deadlock\nin some scenarios.\n\nTrimmed down the call stack, as follows:\n\nf2fs_submit_read_io\n submit_bio //bio_list is initialized.\n mmc_blk_mq_recovery\n z_erofs_endio\n vm_map_ram\n __pte_alloc_kernel\n __alloc_pages_direct_reclaim\n shrink_folio_list\n __swap_writepage\n submit_bio_wait //bio_list is non-NULL, hang!!!\n\nUse memalloc_noio_{save,restore}() to wrap up this path.(CVE-2026-31467)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false\n\nA UAF issue occurs when the virtio_net driver is configured with napi_tx=N\nand the device\u0026apos;s IFF_XMIT_DST_RELEASE flag is cleared\n(e.g., during the configuration of tc route filter rules).\n\nWhen IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack\nexpects the driver to hold the reference to skb-\u0026gt;dst until the packet\nis fully transmitted and freed. In virtio_net with napi_tx=N,\nskbs may remain in the virtio transmit ring for an extended period.\n\nIf the network namespace is destroyed while these skbs are still pending,\nthe corresponding dst_ops structure has freed. When a subsequent packet\nis transmitted, free_old_xmit() is triggered to clean up old skbs.\nIt then calls dst_release() on the skb associated with the stale dst_entry.\nSince the dst_ops (referenced by the dst_entry) has already been freed,\na UAF kernel paging request occurs.\n\nfix it by adds skb_dst_drop(skb) in start_xmit to explicitly release\nthe dst reference before the skb is queued in virtio_net.\n\nCall Trace:\n Unable to handle kernel paging request at virtual address ffff80007e150000\n CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT\n ...\n percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P)\n dst_release+0xe0/0x110 net/core/dst.c:177\n skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177\n sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255\n dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469\n napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527\n __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net]\n free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net]\n start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net]\n ...\n\nReproduction Steps:\nNETDEV=\u0026quot;enp3s0\u0026quot;\n\nconfig_qdisc_route_filter() {\n tc qdisc del dev $NETDEV root\n tc qdisc add dev $NETDEV root handle 1: prio\n tc filter add dev $NETDEV parent 1:0 \\\n\tprotocol ip prio 100 route to 100 flowid 1:1\n ip route add 192.168.1.100/32 dev $NETDEV realm 100\n}\n\ntest_ns() {\n ip netns add testns\n ip link set $NETDEV netns testns\n ip netns exec testns ifconfig $NETDEV 10.0.32.46/24\n ip netns exec testns ping -c 1 10.0.32.1\n ip netns del testns\n}\n\nconfig_qdisc_route_filter\n\ntest_ns\nsleep 2\ntest_ns(CVE-2026-31469)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1]\n\nAlso note that we do not enable the driver_override feature of struct\nbus_type, as SPI - in contrast to most other buses - passes \u0026quot;\u0026quot; to\nsysfs_emit() when the driver_override pointer is NULL. Thus, printing\n\u0026quot;\\n\u0026quot; instead of \u0026quot;(null)\\n\u0026quot;.(CVE-2026-31487)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: use netlink policy range checks\n\nReplace manual range and mask validations with netlink policy\nannotations in ctnetlink code paths, so that the netlink core rejects\ninvalid values early and can generate extack errors.\n\n- CTA_PROTOINFO_TCP_STATE: reject values \u0026gt; TCP_CONNTRACK_SYN_SENT2 at\n policy level, removing the manual \u0026gt;= TCP_CONNTRACK_MAX check.\n- CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values \u0026gt; TCP_MAX_WSCALE\n (14). The normal TCP option parsing path already clamps to this value,\n but the ctnetlink path accepted 0-255, causing undefined behavior when\n used as a u32 shift count.\n- CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with\n CTA_FILTER_F_ALL, removing the manual mask checks.\n- CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding\n a new mask define grouping all valid expect flags.\n\nExtracted from a broader nf-next patch by Florian Westphal, scoped to\nctnetlink for the fixes tree.(CVE-2026-31495)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: skip expectations in other netns via proc\n\nSkip expectations that do not reside in this netns.\n\nSimilar to e77e6ff502ea (\u0026quot;netfilter: conntrack: do not dump other netns\u0026apos;s\nconntrack entries via proc\u0026quot;).(CVE-2026-31496)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop\n\nl2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED\nstate to support L2CAP reconfiguration (e.g. MTU changes). However,\nsince both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from\nthe initial configuration, the reconfiguration path falls through to\nl2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and\nretrans_list without freeing the previous allocations and sets\nchan-\u0026gt;sdu to NULL without freeing the existing skb. This leaks all\npreviously allocated ERTM resources.\n\nAdditionally, l2cap_parse_conf_req() does not validate the minimum\nvalue of remote_mps derived from the RFC max_pdu_size option. A zero\nvalue propagates to l2cap_segment_sdu() where pdu_len becomes zero,\ncausing the while loop to never terminate since len is never\ndecremented, exhausting all available memory.\n\nFix the double-init by skipping l2cap_ertm_init() and\nl2cap_chan_ready() when the channel is already in BT_CONNECTED state,\nwhile still allowing the reconfiguration parameters to be updated\nthrough l2cap_parse_conf_req(). Also add a pdu_len zero check in\nl2cap_segment_sdu() as a safeguard.(CVE-2026-31498)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix deadlock in l2cap_conn_del()\n\nl2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer\nand id_addr_timer while holding conn-\u0026gt;lock. However, the work functions\nl2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire\nconn-\u0026gt;lock, creating a potential AB-BA deadlock if the work is already\nexecuting when l2cap_conn_del() takes the lock.\n\nMove the work cancellations before acquiring conn-\u0026gt;lock and use\ndisable_delayed_work_sync() to additionally prevent the works from\nbeing rearmed after cancellation, consistent with the pattern used in\nhci_conn_del().(CVE-2026-31499)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix out-of-bounds writes in iavf_get_ethtool_stats()\n\niavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the\nvalue could change in runtime, we should use num_tx_queues instead.\n\nMoreover iavf_get_ethtool_stats() uses num_active_queues while\niavf_get_sset_count() and iavf_get_stat_strings() use\nreal_num_tx_queues, which triggers out-of-bounds writes when we do\n\u0026quot;ethtool -L\u0026quot; and \u0026quot;ethtool -S\u0026quot; simultaneously [1].\n\nFor example when we change channels from 1 to 8, Thread 3 could be\nscheduled before Thread 2, and out-of-bounds writes could be triggered\nin Thread 3:\n\nThread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S)\niavf_set_channels()\n...\niavf_alloc_queues()\n-\u0026gt; num_active_queues = 8\niavf_schedule_finish_config()\n iavf_get_sset_count()\n real_num_tx_queues: 1\n -\u0026gt; buffer for 1 queue\n iavf_get_ethtool_stats()\n num_active_queues: 8\n -\u0026gt; out-of-bounds!\n iavf_finish_config()\n -\u0026gt; real_num_tx_queues = 8\n\nUse immutable num_tx_queues in all related functions to avoid the issue.\n\n[1]\n BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270\n Write of size 8 at addr ffffc900031c9080 by task ethtool/5800\n\n CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x180\n iavf_add_one_ethtool_stat+0x200/0x270\n iavf_get_ethtool_stats+0x14c/0x2e0\n __dev_ethtool+0x3d0c/0x5830\n dev_ethtool+0x12d/0x270\n dev_ioctl+0x53c/0xe30\n sock_do_ioctl+0x1a9/0x270\n sock_ioctl+0x3d4/0x5e0\n __x64_sys_ioctl+0x137/0x1c0\n do_syscall_64+0xf3/0x690\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f7da0e6e36d\n ...\n \u0026lt;/TASK\u0026gt;\n\n The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830\n The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000\n index:0xffff88813a013de0 pfn:0x13a013\n flags: 0x200000000000000(node=0|zone=2)\n raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000\n raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8(CVE-2026-31505)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb\n\nBefore using sk pointer, check if it is null.\n\nFix the following:\n\n KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267]\n CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025\n Workqueue: events l2cap_info_timeout\n RIP: 0010:kasan_byte_accessible+0x12/0x30\n Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df \u0026lt;0f\u0026gt; b6 04 07 3c 08 0f 92 c0 c3 cc cce\n veth0_macvtap: entered promiscuous mode\n RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202\n RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001\n RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c\n RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\n R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000\n R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001\n FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __kasan_check_byte+0x12/0x40\n lock_acquire+0x79/0x2e0\n lock_sock_nested+0x48/0x100\n ? l2cap_sock_ready_cb+0x46/0x160\n l2cap_sock_ready_cb+0x46/0x160\n l2cap_conn_start+0x779/0xff0\n ? __pfx_l2cap_conn_start+0x10/0x10\n ? l2cap_info_timeout+0x60/0xa0\n ? __pfx___mutex_lock+0x10/0x10\n l2cap_info_timeout+0x68/0xa0\n ? process_scheduled_works+0xa8d/0x18c0\n process_scheduled_works+0xb6e/0x18c0\n ? __pfx_process_scheduled_works+0x10/0x10\n ? assign_work+0x3d5/0x5e0\n worker_thread+0xa53/0xfc0\n kthread+0x388/0x470\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x51e/0xb90\n ? __pfx_ret_from_fork+0x10/0x10\n veth1_macvtap: entered promiscuous mode\n ? __switch_to+0xc7d/0x1450\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n Modules linked in:\n ---[ end trace 0000000000000000 ]---\n batman_adv: batadv0: Interface activated: batadv_slave_0\n batman_adv: batadv0: Interface activated: batadv_slave_1\n netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0\n netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0\n netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0\n netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0\n RIP: 0010:kasan_byte_accessible+0x12/0x30\n Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df \u0026lt;0f\u0026gt; b6 04 07 3c 08 0f 92 c0 c3 cc cce\n ieee80211 phy39: Selected rate control algorithm \u0026apos;minstrel_ht\u0026apos;\n RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202\n RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001\n RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c\n RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\n R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000\n R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001\n FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0\n PKRU: 55555554\n Kernel panic - not syncing: Fatal exception(CVE-2026-31510)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete\n\nThis fixes the condition checking so mgmt_pending_valid is executed\nwhenever status != -ECANCELED otherwise calling mgmt_pending_free(cmd)\nwould kfree(cmd) without unlinking it from the list first, leaving a\ndangling pointer. Any subsequent list traversal (e.g.,\nmgmt_pending_foreach during __mgmt_power_off, or another\nmgmt_pending_valid call) would dereference freed memory.(CVE-2026-31511)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()\n\nl2cap_ecred_data_rcv() reads the SDU length field from skb-\u0026gt;data using\nget_unaligned_le16() without first verifying that skb contains at least\nL2CAP_SDULEN_SIZE (2) bytes. When skb-\u0026gt;len is less than 2, this reads\npast the valid data in the skb.\n\nThe ERTM reassembly path correctly calls pskb_may_pull() before reading\nthe SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the\nsame validation to the Enhanced Credit Based Flow Control data path.(CVE-2026-31512)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: prevent policy_hthresh.work from racing with netns teardown\n\nA XFRM_MSG_NEWSPDINFO request can queue the per-net work item\npolicy_hthresh.work onto the system workqueue.\n\nThe queued callback, xfrm_hash_rebuild(), retrieves the enclosing\nstruct net via container_of(). If the net namespace is torn down\nbefore that work runs, the associated struct net may already have\nbeen freed, and xfrm_hash_rebuild() may then dereference stale memory.\n\nxfrm_policy_fini() already flushes policy_hash_work during teardown,\nbut it does not synchronize policy_hthresh.work.\n\nSynchronize policy_hthresh.work in xfrm_policy_fini() as well, so the\nqueued work cannot outlive the net namespace teardown and access a\nfreed struct net.(CVE-2026-31516)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nesp: fix skb leak with espintcp and async crypto\n\nWhen the TX queue for espintcp is full, esp_output_tail_tcp will\nreturn an error and not free the skb, because with synchronous crypto,\nthe common xfrm output code will drop the packet for us.\n\nWith async crypto (esp_output_done), we need to drop the skb when\nesp_output_tail_tcp returns an error.(CVE-2026-31518)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN\n\nThe BPF interpreter\u0026apos;s signed 32-bit division and modulo handlers use\nthe kernel abs() macro on s32 operands. The abs() macro documentation\n(include/linux/math.h) explicitly states the result is undefined when\nthe input is the type minimum. When DST contains S32_MIN (0x80000000),\nabs((s32)DST) triggers undefined behavior and returns S32_MIN unchanged\non arm64/x86. This value is then sign-extended to u64 as\n0xFFFFFFFF80000000, causing do_div() to compute the wrong result.\n\nThe verifier\u0026apos;s abstract interpretation (scalar32_min_max_sdiv) computes\nthe mathematically correct result for range tracking, creating a\nverifier/interpreter mismatch that can be exploited for out-of-bounds\nmap value access.\n\nIntroduce abs_s32() which handles S32_MIN correctly by casting to u32\nbefore negating, avoiding signed overflow entirely. Replace all 8\nabs((s32)...) call sites in the interpreter\u0026apos;s sdiv32/smod32 handlers.\n\ns32 is the only affected case -- the s64 division/modulo handlers do\nnot use abs().(CVE-2026-31525)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Make sure to use pmu_ctx-\u0026gt;pmu for groups\n\nOliver reported that x86_pmu_del() ended up doing an out-of-bound memory access\nwhen group_sched_in() fails and needs to roll back.\n\nThis *should* be handled by the transaction callbacks, but he found that when\nthe group leader is a software event, the transaction handlers of the wrong PMU\nare used. Despite the move_group case in perf_event_open() and group_sched_in()\nusing pmu_ctx-\u0026gt;pmu.\n\nTurns out, inherit uses event-\u0026gt;pmu to clone the events, effectively undoing the\nmove_group case for all inherited contexts. Fix this by also making inherit use\npmu_ctx-\u0026gt;pmu, ensuring all inherited counters end up in the same pmu context.\n\nSimilarly, __perf_event_read() should use equally use pmu_ctx-\u0026gt;pmu for the\ngroup case.(CVE-2026-31528)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: raw: fix ro-\u0026gt;uniq use-after-free in raw_rcv()\n\nraw_release() unregisters raw CAN receive filters via can_rx_unregister(),\nbut receiver deletion is deferred with call_rcu(). This leaves a window\nwhere raw_rcv() may still be running in an RCU read-side critical section\nafter raw_release() frees ro-\u0026gt;uniq, leading to a use-after-free of the\npercpu uniq storage.\n\nMove free_percpu(ro-\u0026gt;uniq) out of raw_release() and into a raw-specific\nsocket destructor. can_rx_unregister() takes an extra reference to the\nsocket and only drops it from the RCU callback, so freeing uniq from\nsk_destruct ensures the percpu area is not released until the relevant\ncallbacks have drained.\n\n[mkl: applied manually](CVE-2026-31532)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tls: fix use-after-free in -EBUSY error path of tls_do_encryption\n\nThe -EBUSY handling in tls_do_encryption(), introduced by commit\n859054147318 (\u0026quot;net: tls: handle backlogging of crypto requests\u0026quot;), has\na use-after-free due to double cleanup of encrypt_pending and the\nscatterlist entry.\n\nWhen crypto_aead_encrypt() returns -EBUSY, the request is enqueued to\nthe cryptd backlog and the async callback tls_encrypt_done() will be\ninvoked upon completion. That callback unconditionally restores the\nscatterlist entry (sge-\u0026gt;offset, sge-\u0026gt;length) and decrements\nctx-\u0026gt;encrypt_pending. However, if tls_encrypt_async_wait() returns an\nerror, the synchronous error path in tls_do_encryption() performs the\nsame cleanup again, double-decrementing encrypt_pending and\ndouble-restoring the scatterlist.\n\nThe double-decrement corrupts the encrypt_pending sentinel (initialized\nto 1), making tls_encrypt_async_wait() permanently skip the wait for\npending async callbacks. A subsequent sendmsg can then free the\ntls_rec via bpf_exec_tx_verdict() while a cryptd callback is still\npending, resulting in a use-after-free when the callback fires on the\nfreed record.\n\nFix this by skipping the synchronous cleanup when the -EBUSY async\nwait returns an error, since the callback has already handled\nencrypt_pending and sge restoration.(CVE-2026-31533)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Check set_default_submission() before deferencing\n\nWhen the i915 driver firmware binaries are not present, the\nset_default_submission pointer is not set. This pointer is\ndereferenced during suspend anyways.\n\nAdd a check to make sure it is set before dereferencing.\n\n[ 23.289926] PM: suspend entry (deep)\n[ 23.293558] Filesystems sync: 0.000 seconds\n[ 23.298010] Freezing user space processes\n[ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds)\n[ 23.309766] OOM killer disabled.\n[ 23.313027] Freezing remaining freezable tasks\n[ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)\n[ 23.342038] serial 00:05: disabled\n[ 23.345719] serial 00:02: disabled\n[ 23.349342] serial 00:01: disabled\n[ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache\n[ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache\n[ 23.361635] ata1.00: Entering standby power mode\n[ 23.368863] ata2.00: Entering standby power mode\n[ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 23.452194] #PF: supervisor instruction fetch in kernel mode\n[ 23.457896] #PF: error_code(0x0010) - not-present page\n[ 23.463065] PGD 0 P4D 0\n[ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI\n[ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary)\n[ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN\n[ 23.496511] Workqueue: async async_run_entry_fn\n[ 23.501087] RIP: 0010:0x0\n[ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n[ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246\n[ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f\n[ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000\n[ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff\n[ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8\n[ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68\n[ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000\n[ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0\n[ 23.572539] PKRU: 55555554\n[ 23.575281] Call Trace:\n[ 23.577770] \u0026lt;TASK\u0026gt;\n[ 23.579905] intel_engines_reset_default_submission+0x42/0x60\n[ 23.585695] __intel_gt_unset_wedged+0x191/0x200\n[ 23.590360] intel_gt_unset_wedged+0x20/0x40\n[ 23.594675] gt_sanitize+0x15e/0x170\n[ 23.598290] i915_gem_suspend_late+0x6b/0x180\n[ 23.602692] i915_drm_suspend_late+0x35/0xf0\n[ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10\n[ 23.611843] dpm_run_callback+0x78/0x1c0\n[ 23.615817] device_suspend_late+0xde/0x2e0\n[ 23.620037] async_suspend_late+0x18/0x30\n[ 23.624082] async_run_entry_fn+0x25/0xa0\n[ 23.628129] process_one_work+0x15b/0x380\n[ 23.632182] worker_thread+0x2a5/0x3c0\n[ 23.635973] ? __pfx_worker_thread+0x10/0x10\n[ 23.640279] kthread+0xf6/0x1f0\n[ 23.643464] ? __pfx_kthread+0x10/0x10\n[ 23.647263] ? __pfx_kthread+0x10/0x10\n[ 23.651045] ret_from_fork+0x131/0x190\n[ 23.654837] ? __pfx_kthread+0x10/0x10\n[ 23.658634] ret_from_fork_asm+0x1a/0x30\n[ 23.662597] \u0026lt;/TASK\u0026gt;\n[ 23.664826] Modules linked in:\n[ 23.667914] CR2: 0000000000000000\n[ 23.671271] ------------[ cut here ]------------\n\n(cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)(CVE-2026-31540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/platform/uv: Handle deconfigured sockets\n\nWhen a socket is deconfigured, it\u0026apos;s mapped to SOCK_EMPTY (0xffff). This causes\na panic while allocating UV hub info structures.\n\nFix this by using NUMA_NO_NODE, allowing UV hub info structures to be\nallocated on valid nodes.(CVE-2026-31542)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bonding: fix NULL deref in bond_debug_rlb_hash_show\n\nrlb_clear_slave intentionally keeps RLB hash-table entries on\nthe rx_hashtbl_used_head list with slave set to NULL when no\nreplacement slave is available. However, bond_debug_rlb_hash_show\nvisites client_info-\u0026gt;slave without checking if it\u0026apos;s NULL.\n\nOther used-list iterators in bond_alb.c already handle this NULL-slave\nstate safely:\n\n- rlb_update_client returns early on !client_info-\u0026gt;slave\n- rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance\ncompare slave values before visiting\n- lb_req_update_subnet_clients continues if slave is NULL\n\nThe following NULL deref crash can be trigger in\nbond_debug_rlb_hash_show:\n\n[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41)\n[ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286\n[ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204\n[ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078\n[ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000\n[ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0\n[ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8\n[ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000\n[ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0\n[ 1.295897] Call Trace:\n[ 1.296134] seq_read_iter (fs/seq_file.c:231)\n[ 1.296341] seq_read (fs/seq_file.c:164)\n[ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1))\n[ 1.296658] vfs_read (fs/read_write.c:572)\n[ 1.296981] ksys_read (fs/read_write.c:717)\n[ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n[ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nAdd a NULL check and print \u0026quot;(none)\u0026quot; for entries with no assigned slave.(CVE-2026-31546)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Clear stale exiting pointer in futex_lock_pi() retry path\n\nFuzzying/stressing futexes triggered:\n\n WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524\n\nWhen futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY\nand stores a refcounted task pointer in \u0026apos;exiting\u0026apos;.\n\nAfter wait_for_owner_exiting() consumes that reference, the local pointer\nis never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a\ndifferent error, the bogus pointer is passed to wait_for_owner_exiting().\n\n CPU0\t\t\t CPU1\t\t CPU2\n futex_lock_pi(uaddr)\n // acquires the PI futex\n exit()\n futex_cleanup_begin()\n futex_state = EXITING;\n\t\t\t futex_lock_pi(uaddr)\n\t\t\t futex_lock_pi_atomic()\n\t\t\t\t attach_to_pi_owner()\n\t\t\t\t // observes EXITING\n\t\t\t\t *exiting = owner; // takes ref\n\t\t\t\t return -EBUSY\n\t\t\t wait_for_owner_exiting(-EBUSY, owner)\n\t\t\t\t put_task_struct(); // drops ref\n\t\t\t // exiting still points to owner\n\t\t\t goto retry;\n\t\t\t futex_lock_pi_atomic()\n\t\t\t\t lock_pi_update_atomic()\n\t\t\t\t cmpxchg(uaddr)\n\t\t\t\t\t*uaddr ^= WAITERS // whatever\n\t\t\t\t // value changed\n\t\t\t\t return -EAGAIN;\n\t\t\t wait_for_owner_exiting(-EAGAIN, exiting) // stale\n\t\t\t\t WARN_ON_ONCE(exiting)\n\nFix this by resetting upon retry, essentially aligning it with requeue_pi.(CVE-2026-31555)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib\n\namdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence\nfrom amdgpu_ib_schedule(). This fence is used to wait for job\ncompletion.\n\nCurrently, the code drops the fence reference using dma_fence_put()\nbefore calling dma_fence_wait().\n\nIf dma_fence_put() releases the last reference, the fence may be\nfreed before dma_fence_wait() is called. This can lead to a\nuse-after-free.\n\nFix this by waiting on the fence first and releasing the reference\nonly after dma_fence_wait() completes.\n\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory \u0026apos;f\u0026apos; (line 696)\n\n(cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)(CVE-2026-31566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: gw: fix OOB heap access in cgw_csum_crc8_rel()\n\ncgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():\n\n int from = calc_idx(crc8-\u0026gt;from_idx, cf-\u0026gt;len);\n int to = calc_idx(crc8-\u0026gt;to_idx, cf-\u0026gt;len);\n int res = calc_idx(crc8-\u0026gt;result_idx, cf-\u0026gt;len);\n\n if (from \u0026lt; 0 || to \u0026lt; 0 || res \u0026lt; 0)\n return;\n\nHowever, the loop and the result write then use the raw s8 fields directly\ninstead of the computed variables:\n\n for (i = crc8-\u0026gt;from_idx; ...) /* BUG: raw negative index */\n cf-\u0026gt;data[crc8-\u0026gt;result_idx] = ...; /* BUG: raw negative index */\n\nWith from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,\ncalc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with\ni = -64, reading cf-\u0026gt;data[-64], and the write goes to cf-\u0026gt;data[-64].\nThis write might end up to 56 (7.0-rc) or 40 (\u0026lt;= 6.19) bytes before the\nstart of the canfd_frame on the heap.\n\nThe companion function cgw_csum_xor_rel() uses `from`/`to`/`res`\ncorrectly throughout; fix cgw_csum_crc8_rel() to match.\n\nConfirmed with KASAN on linux-7.0-rc2:\n BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0\n Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62\n\nTo configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.(CVE-2026-31570)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION\n\nDrop the WARN in sev_pin_memory() on npages overflowing an int, as the\nWARN is comically trivially to trigger from userspace, e.g. by doing:\n\n struct kvm_enc_region range = {\n .addr = 0,\n .size = -1ul,\n };\n\n __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, \u0026amp;range);\n\nNote, the checks in sev_mem_enc_register_region() that presumably exist to\nverify the incoming address+size are completely worthless, as both \u0026quot;addr\u0026quot;\nand \u0026quot;size\u0026quot; are u64s and SEV is 64-bit only, i.e. they _can\u0026apos;t_ be greater\nthan ULONG_MAX. That wart will be cleaned up in the near future.\n\n\tif (range-\u0026gt;addr \u0026gt; ULONG_MAX || range-\u0026gt;size \u0026gt; ULONG_MAX)\n\t\treturn -EINVAL;\n\nOpportunistically add a comment to explain why the code calculates the\nnumber of pages the \u0026quot;hard\u0026quot; way, e.g. instead of just shifting @ulen.(CVE-2026-31590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup\n\nDisable the delayed work before clearing BAR mappings and doorbells to\navoid running the handler after resources have been torn down.\n\n Unable to handle kernel paging request at virtual address ffff800083f46004\n [...]\n Internal error: Oops: 0000000096000007 [#1] SMP\n [...]\n Call trace:\n epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P)\n process_one_work+0x154/0x3b0\n worker_thread+0x2c8/0x400\n kthread+0x148/0x210\n ret_from_fork+0x10/0x20(CVE-2026-31595)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU: Fix FPDSS on Zen1\n\nZen1\u0026apos;s hardware divider can leave, under certain circumstances, partial\nresults from previous operations. Those results can be leaked by\nanother, attacker thread.\n\nFix that with a chicken bit.(CVE-2026-31628)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: proc: size address buffers for %pISpc output\n\nThe AF_RXRPC procfs helpers format local and remote socket addresses into\nfixed 50-byte stack buffers with \u0026quot;%pISpc\u0026quot;.\n\nThat is too small for the longest current-tree IPv6-with-port form the\nformatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a\ndotted-quad tail not only for v4mapped addresses, but also for ISATAP\naddresses via ipv6_addr_is_isatap().\n\nAs a result, a case such as\n\n [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535\n\nis possible with the current formatter. That is 50 visible characters, so\n51 bytes including the trailing NUL, which does not fit in the existing\nchar[50] buffers used by net/rxrpc/proc.c.\n\nSize the buffers from the formatter\u0026apos;s maximum textual form and switch the\ncall sites to scnprintf().\n\nChanges since v1:\n- correct the changelog to cite the actual maximum current-tree case\n explicitly\n- frame the proof around the ISATAP formatting path instead of the earlier\n mapped-v4 example(CVE-2026-31630)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: vub300: fix NULL-deref on disconnect\n\nMake sure to deregister the controller before dropping the reference to\nthe driver data on disconnect to avoid NULL-pointer dereferences or\nuse-after-free.(CVE-2026-31651)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: fix use-after-free in timeout object destroy\n\nnft_ct_timeout_obj_destroy() frees the timeout object with kfree()\nimmediately after nf_ct_untimeout(), without waiting for an RCU grace\nperiod. Concurrent packet processing on other CPUs may still hold\nRCU-protected references to the timeout object obtained via\nrcu_dereference() in nf_ct_timeout_data().\n\nAdd an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer\nfreeing until after an RCU grace period, matching the approach already\nused in nfnetlink_cttimeout.c.\n\nKASAN report:\n BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0\n Read of size 4 at addr ffff8881035fe19c by task exploit/80\n\n Call Trace:\n nf_conntrack_tcp_packet+0x1381/0x29d0\n nf_conntrack_in+0x612/0x8b0\n nf_hook_slow+0x70/0x100\n __ip_local_out+0x1b2/0x210\n tcp_sendmsg_locked+0x722/0x1580\n __sys_sendto+0x2d8/0x320\n\n Allocated by task 75:\n nft_ct_timeout_obj_init+0xf6/0x290\n nft_obj_init+0x107/0x1b0\n nf_tables_newobj+0x680/0x9c0\n nfnetlink_rcv_batch+0xc29/0xe00\n\n Freed by task 26:\n nft_obj_destroy+0x3f/0xa0\n nf_tables_trans_destroy_work+0x51c/0x5c0\n process_one_work+0x2c4/0x5a0(CVE-2026-31665)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: uinput - fix circular locking dependency with ff-core\n\nA lockdep circular locking dependency warning can be triggered\nreproducibly when using a force-feedback gamepad with uinput (for\nexample, playing ELDEN RING under Wine with a Flydigi Vader 5\ncontroller):\n\n ff-\u0026gt;mutex -\u0026gt; udev-\u0026gt;mutex -\u0026gt; input_mutex -\u0026gt; dev-\u0026gt;mutex -\u0026gt; ff-\u0026gt;mutex\n\nThe cycle is caused by four lock acquisition paths:\n\n1. ff upload: input_ff_upload() holds ff-\u0026gt;mutex and calls\n uinput_dev_upload_effect() -\u0026gt; uinput_request_submit() -\u0026gt;\n uinput_request_send(), which acquires udev-\u0026gt;mutex.\n\n2. device create: uinput_ioctl_handler() holds udev-\u0026gt;mutex and calls\n uinput_create_device() -\u0026gt; input_register_device(), which acquires\n input_mutex.\n\n3. device register: input_register_device() holds input_mutex and\n calls kbd_connect() -\u0026gt; input_register_handle(), which acquires\n dev-\u0026gt;mutex.\n\n4. evdev release: evdev_release() calls input_flush_device() under\n dev-\u0026gt;mutex, which calls input_ff_flush() acquiring ff-\u0026gt;mutex.\n\nFix this by introducing a new state_lock spinlock to protect\nudev-\u0026gt;state and udev-\u0026gt;dev access in uinput_request_send() instead of\nacquiring udev-\u0026gt;mutex. The function only needs to atomically check\ndevice state and queue an input event into the ring buffer via\nuinput_dev_event() -- both operations are safe under a spinlock\n(ktime_get_ts64() and wake_up_interruptible() do not sleep). This\nbreaks the ff-\u0026gt;mutex -\u0026gt; udev-\u0026gt;mutex link since a spinlock is a leaf in\nthe lock ordering and cannot form cycles with mutexes.\n\nTo keep state transitions visible to uinput_request_send(), protect\nwrites to udev-\u0026gt;state in uinput_create_device() and\nuinput_destroy_device() with the same state_lock spinlock.\n\nAdditionally, move init_completion(\u0026amp;request-\u0026gt;done) from\nuinput_request_send() to uinput_request_submit() before\nuinput_request_reserve_slot(). Once the slot is allocated,\nuinput_flush_requests() may call complete() on it at any time from\nthe destroy path, so the completion must be initialised before the\nrequest becomes visible.\n\nLock ordering after the fix:\n\n ff-\u0026gt;mutex -\u0026gt; state_lock (spinlock, leaf)\n udev-\u0026gt;mutex -\u0026gt; state_lock (spinlock, leaf)\n udev-\u0026gt;mutex -\u0026gt; input_mutex -\u0026gt; dev-\u0026gt;mutex -\u0026gt; ff-\u0026gt;mutex (no back-edge)(CVE-2026-31667)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_netem: fix out-of-bounds access in packet corruption\n\nIn netem_enqueue(), the packet corruption logic uses\nget_random_u32_below(skb_headlen(skb)) to select an index for\nmodifying skb-\u0026gt;data. When an AF_PACKET TX_RING sends fully non-linear\npackets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.\n\nPassing 0 to get_random_u32_below() takes the variable-ceil slow path\nwhich returns an unconstrained 32-bit random integer. Using this\nunconstrained value as an offset into skb-\u0026gt;data results in an\nout-of-bounds memory access.\n\nFix this by verifying skb_headlen(skb) is non-zero before attempting\nto corrupt the linear data area. Fully non-linear packets will silently\nbypass the corruption logic.(CVE-2026-31675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - limit RX SG extraction by receive buffer budget\n\nMake af_alg_get_rsgl() limit each RX scatterlist extraction to the\nremaining receive buffer budget.\n\naf_alg_get_rsgl() currently uses af_alg_readable() only as a gate\nbefore extracting data into the RX scatterlist. Limit each extraction\nto the remaining af_alg_rcvbuf(sk) budget so that receive-side\naccounting matches the amount of data attached to the request.\n\nIf skcipher cannot obtain enough RX space for at least one chunk while\nmore data remains to be processed, reject the recvmsg call instead of\nrounding the request length down to zero.(CVE-2026-31677)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: defer tunnel netdev_put to RCU release\n\novs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already\ndetached the device. Dropping the netdev reference in destroy can race\nwith concurrent readers that still observe vport-\u0026gt;dev.\n\nDo not release vport-\u0026gt;dev in ovs_netdev_tunnel_destroy(). Instead, let\nvport_netdev_free() drop the reference from the RCU callback, matching\nthe non-tunnel destroy path and avoiding additional synchronization\nunder RTNL.(CVE-2026-31678)\n\nIn the Linux kernel, a memory out-of-bounds access vulnerability exists in the act_csum module\u0026apos;s tcf_csum_act() function when processing nested VLAN headers. When an skb still carries in-payload VLAN tags, the function walks nested VLAN headers directly from skb-\u0026gt;data. The current code reads vlan-\u0026gt;h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants.(CVE-2026-31684)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ip6t_eui64: reject invalid MAC header for all packets\n\n`eui64_mt6()` derives a modified EUI-64 from the Ethernet source address\nand compares it with the low 64 bits of the IPv6 source address.\n\nThe existing guard only rejects an invalid MAC header when\n`par-\u0026gt;fragoff != 0`. For packets with `par-\u0026gt;fragoff == 0`, `eui64_mt6()`\ncan still reach `eth_hdr(skb)` even when the MAC header is not valid.\n\nFix this by removing the `par-\u0026gt;fragoff != 0` condition so that packets\nwith an invalid MAC header are rejected before accessing `eth_hdr(skb)`.(CVE-2026-31685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/mc: Fix error path ordering in edac_mc_alloc()\n\nWhen the mci-\u0026gt;pvt_info allocation in edac_mc_alloc() fails, the error path\nwill call put_device() which will end up calling the device\u0026apos;s release\nfunction.\n\nHowever, the init ordering is wrong such that device_initialize() happens\n*after* the failed allocation and thus the device itself and the release\nfunction pointer are not initialized yet when they\u0026apos;re called:\n\n MCE: In-kernel MCE decoding enabled.\n ------------[ cut here ]------------\n kobject: \u0026apos;(null)\u0026apos;: is not initialized, yet kobject_put() is being called.\n WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd\n CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)\n RIP: 0010:kobject_put\n Call Trace:\n \u0026lt;TASK\u0026gt;\n edac_mc_alloc+0xbe/0xe0 [edac_core]\n amd64_edac_init+0x7a4/0xff0 [amd64_edac]\n ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]\n do_one_initcall\n ...\n\nReorder the calling sequence so that the device is initialized and thus the\nrelease function pointer is properly set before it can be used.\n\nThis was found by Claude while reviewing another EDAC patch.(CVE-2026-31689)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don\u0026apos;t attempt to copy ID to userspace if PSP command failed\n\nWhen retrieving the ID for the CPU, don\u0026apos;t attempt to copy the ID blob to\nuserspace if the firmware command failed. If the failure was due to an\ninvalid length, i.e. the userspace buffer+length was too small, copying\nthe number of bytes _firmware_ requires will overflow the kernel-allocated\nbuffer and leak data to userspace.\n\n BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388\n\n CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n print_address_description ../mm/kasan/report.c:378 [inline]\n print_report+0xbc/0x260 ../mm/kasan/report.c:482\n kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n check_region_inline ../mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n copy_to_user ../include/linux/uaccess.h:236 [inline]\n sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222\n sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575\n vfs_ioctl ../fs/ioctl.c:51 [inline]\n __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don\u0026apos;t attempt to copy PDH cert to userspace if PSP command failed\n\nWhen retrieving the PDH cert, don\u0026apos;t attempt to copy the blobs to userspace\nif the firmware command failed. If the failure was due to an invalid\nlength, i.e. the userspace buffer+length was too small, copying the number\nof bytes _firmware_ requires will overflow the kernel-allocated buffer and\nleak data to userspace.\n\n BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033\n\n CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n print_address_description ../mm/kasan/report.c:378 [inline]\n print_report+0xbc/0x260 ../mm/kasan/report.c:482\n kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n check_region_inline ../mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n copy_to_user ../include/linux/uaccess.h:236 [inline]\n sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347\n sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568\n vfs_ioctl ../fs/ioctl.c:51 [inline]\n __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31698)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don\u0026apos;t attempt to copy CSR to userspace if PSP command failed\n\nWhen retrieving the PEK CSR, don\u0026apos;t attempt to copy the blob to userspace\nif the firmware command failed. If the failure was due to an invalid\nlength, i.e. the userspace buffer+length was too small, copying the number\nof bytes _firmware_ requires will overflow the kernel-allocated buffer and\nleak data to userspace.\n\n BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405\n\n CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n print_address_description ../mm/kasan/report.c:378 [inline]\n print_report+0xbc/0x260 ../mm/kasan/report.c:482\n kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n check_region_inline ../mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n copy_to_user ../include/linux/uaccess.h:236 [inline]\n sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872\n sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562\n vfs_ioctl ../fs/ioctl.c:51 [inline]\n __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31699)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path\n\nsmb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL\nand the default QUERY_INFO path. The QUERY_INFO branch clamps\nqi.input_buffer_length to the server-reported OutputBufferLength and then\ncopies qi.input_buffer_length bytes from qi_rsp-\u0026gt;Buffer to userspace, but\nit never verifies that the flexible-array payload actually fits within\nrsp_iov[1].iov_len.\n\nA malicious server can return OutputBufferLength larger than the actual\nQUERY_INFO response, causing copy_to_user() to walk past the response\nbuffer and expose adjacent kernel heap to userspace.\n\nGuard the QUERY_INFO copy with a bounds check on the actual Buffer\npayload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)\nrather than an open-coded addition so the guard cannot overflow on\n32-bit builds.(CVE-2026-31708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: validate ND option lengths in vxlan_na_create\n\nvxlan_na_create() walks ND options according to option-provided\nlengths. A malformed option can make the parser advance beyond the\ncomputed option span or use a too-short source LLADDR option payload.\n\nValidate option lengths against the remaining NS option area before\nadvancing, and only read source LLADDR when the option is large enough\nfor an Ethernet address.(CVE-2026-31738)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: fix NULL pointer dereference in ep_queue\n\nWhen the gadget endpoint is disabled or not yet configured, the ep-\u0026gt;desc\npointer can be NULL. This leads to a NULL pointer dereference when\n__cdns3_gadget_ep_queue() is called, causing a kernel crash.\n\nAdd a check to return -ESHUTDOWN if ep-\u0026gt;desc is NULL, which is the\nstandard return code for unconfigured endpoints.\n\nThis prevents potential crashes when ep_queue is called on endpoints\nthat are not ready.(CVE-2026-31755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: move wake reason storage into validated event handlers\n\nhci_store_wake_reason() is called from hci_event_packet() immediately\nafter stripping the HCI event header but before hci_event_func()\nenforces the per-event minimum payload length from hci_ev_table.\nThis means a short HCI event frame can reach bacpy() before any bounds\ncheck runs.\n\nRather than duplicating skb parsing and per-event length checks inside\nhci_store_wake_reason(), move wake-address storage into the individual\nevent handlers after their existing event-length validation has\nsucceeded. Convert hci_store_wake_reason() into a small helper that only\nstores an already-validated bdaddr while the caller holds hci_dev_lock().\nUse the same helper after hci_event_func() with a NULL address to\npreserve the existing unexpected-wake fallback semantics when no\nvalidated event handler records a wake address.\n\nAnnotate the helper with __must_hold(\u0026amp;hdev-\u0026gt;lock) and add\nlockdep_assert_held(\u0026amp;hdev-\u0026gt;lock) so future call paths keep the lock\ncontract explicit.\n\nCall the helper from hci_conn_request_evt(), hci_conn_complete_evt(),\nhci_sync_conn_complete_evt(), le_conn_complete_evt(),\nhci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),\nhci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and\nhci_le_past_received_evt().(CVE-2026-31771)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SMP: derive legacy responder STK authentication from MITM state\n\nThe legacy responder path in smp_random() currently labels the stored\nSTK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH.\nThat reflects what the local service requested, not what the pairing\nflow actually achieved.\n\nFor Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear\nand the resulting STK should remain unauthenticated even if the local\nside requested HIGH security. Use the established MITM state when\nstoring the responder STK so the key metadata matches the pairing result.\n\nThis also keeps the legacy path aligned with the Secure Connections code,\nwhich already treats JUST_WORKS/JUST_CFM as unauthenticated.(CVE-2026-31773)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler()\n\nThe memcpy function assumes the dynamic array notif-\u0026gt;matches is at least\nas large as the number of bytes to copy. Otherwise, results-\u0026gt;matches may\ncontain unwanted data. To guarantee safety, extend the validation in one\nof the checks to ensure sufficient packet length.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-31779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ioc32: stop speculation on the drm_compat_ioctl path\n\nThe drm compat ioctl path takes a user controlled pointer, and then\ndereferences it into a table of function pointers, the signature method\nof spectre problems. Fix this up by calling array_index_nospec() on the\nindex to the function pointer list.(CVE-2026-31781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: validate LTK enc_size on load\n\nLoad Long Term Keys stores the user-provided enc_size and later uses\nit to size fixed-size stack operations when replying to LE LTK\nrequests. An enc_size larger than the 16-byte key buffer can therefore\noverflow the reply stack buffer.\n\nReject oversized enc_size values while validating the management LTK\nrecord so invalid keys never reach the stored key state.(CVE-2026-43020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use skb_header_pointer() for TCPv4 GSO frag_off check\n\nSyzbot reported a KMSAN uninit-value warning in gso_features_check()\ncalled from netif_skb_features() [1].\n\ngso_features_check() reads iph-\u0026gt;frag_off to decide whether to clear\nmangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr()\ncan rely on skb header offsets that are not always safe for direct\ndereference on packets injected from PF_PACKET paths.\n\nUse skb_header_pointer() for the TCPv4 frag_off check so the header read\nis robust whether data is already linear or needs copying.\n\n[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407(CVE-2026-43036)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak\n\nWhen processing Router Advertisements with user options the kernel\nbuilds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct\nhas three padding fields that are never zeroed and can leak kernel data\n\nThe fix is simple, just zeroes the padding fields.(CVE-2026-43040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af-alg - fix NULL pointer dereference in scatterwalk\n\nThe AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL)\nwhen chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL\nexactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent\nsendmsg() allocates a new SGL and chains it, but fails to clear the end\nmarker on the previous SGL\u0026apos;s last data entry.\n\nThis causes the crypto scatterwalk to hit a premature end, returning NULL\non sg_next() and leading to a kernel panic during dereference.\n\nFix this by explicitly unmarking the end of the previous SGL when\nperforming sg_chain() in af_alg_alloc_tsgl().(CVE-2026-43043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix not releasing workqueue on .release()\n\nThe workqueue associated with an DSA/IAA device is not released when\nthe object is freed.(CVE-2026-43064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/uncore: Skip discovery table for offline dies\n\nThis warning can be triggered if NUMA is disabled and the system\nboots with fewer CPUs than the number of CPUs in die 0.\n\nWARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]\n\nCurrently, the discovery table continues to be parsed even if all CPUs\nin the associated die are offline. This can lead to an array overflow\nat \u0026quot;pmu-\u0026gt;boxes[die] = box\u0026quot; in uncore_pci_pmu_register(), which may\ntrigger the warning above or cause other issues.(CVE-2026-43079)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/smp: Add check for kcalloc() failure in parse_thread_groups()\n\nAs kcalloc() may fail, check its return value to avoid a NULL pointer\ndereference when passing it to of_property_read_u32_array().(CVE-2026-43148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE\n\nThe arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE -\nwhich is a valid index - so add a check for this.(CVE-2026-43212)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: fiemap page fault fix\n\nIn gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode\nglock. This can lead to recursive glock taking if the fiemap buffer is\nmemory mapped to the same inode and accessing it triggers a page fault.\n\nFix by disabling page faults for iomap_fiemap() and faulting in the\nbuffer by hand if necessary.\n\nFixes xfstest generic/742.(CVE-2026-43262)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: supply snapshot context in ceph_zero_partial_object()\n\nThe ceph_zero_partial_object function was missing proper snapshot\ncontext for its OSD write operations, which could lead to data\ninconsistencies in snapshots.\n\nReproducer:\n../src/vstart.sh --new -x --localhost --bluestore\n./bin/ceph auth caps client.fs_a mds \u0026apos;allow rwps fsname=a\u0026apos; mon \u0026apos;allow r fsname=a\u0026apos; osd \u0026apos;allow rw tag cephfs data=a\u0026apos;\nmount -t ceph (CVE-2026-43273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipa: fix event ring index not programmed for IPA v5.0+\n\nFor IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to\nCH_C_CNTXT_1. The v5.0 register definition intended to define this\nfield in the CH_C_CNTXT_1 fmask array but used the old identifier of\nERINDEX instead of CH_ERINDEX.\n\nWithout a valid event ring, GSI channels could never signal transfer\ncompletions. This caused gsi_channel_trans_quiesce() to block\nforever in wait_for_completion().\n\nAt least for IPA v5.2 this resolves an issue seen where runtime\nsuspend, system suspend, and remoteproc stop all hanged forever. It\nalso meant the IPA data path was completely non functional.(CVE-2026-43345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix memory leaks in ceph_mdsc_build_path()\n\nAdd __putname() calls to error code paths that did not free the \u0026quot;path\u0026quot;\npointer obtained by __getname(). If ownership of this pointer is not\npassed to the caller via path_info.path, the function must free it\nbefore returning.(CVE-2026-43419)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Limit the length of unkillable synchronous timeouts\n\nThe usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in\nusbcore allow unlimited timeout durations. And since they use\nuninterruptible waits, this leaves open the possibility of hanging a\ntask for an indefinitely long time, with no way to kill it short of\nunplugging the target device.\n\nTo prevent this sort of problem, enforce a maximum limit on the length\nof these unkillable timeouts. The limit chosen here, somewhat\narbitrarily, is 60 seconds. On many systems (although not all) this\nis short enough to avoid triggering the kernel\u0026apos;s hung-task detector.\n\nIn addition, clear up the ambiguity of negative timeout values by\ntreating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)\n\nIn the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. The Linux kernel CVE team has assigned CVE-2026-43493 to this issue.(CVE-2026-43493)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skbuff: propagate shared-frag marker through frag-transfer helpers\n\nTwo frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail\nto propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()-\u0026gt;flags when\nmoving frags from source to destination. __pskb_copy_fclone() defers\nthe rest of the shinfo metadata to skb_copy_header() after copying\nfrag descriptors, but that helper only carries over gso_{size,segs,\ntype} and never touches skb_shinfo()-\u0026gt;flags; skb_shift() moves frag\ndescriptors directly and leaves flags untouched. As a result, the\ndestination skb keeps a reference to the same externally-owned or\npage-cache-backed pages while reporting skb_has_shared_frag() as\nfalse.\n\nThe mismatch is harmful in any in-place writer that uses\nskb_has_shared_frag() to decide whether shared pages must be detoured\nthrough skb_cow_data(). ESP input is one such writer (esp4.c,\nesp6.c), and a single nft \u0026apos;dup to \u0026lt;local\u0026gt;\u0026apos; rule -- or any other\nnf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()\u0026apos;d\nskb in esp_input() with the marker stripped, letting an unprivileged\nuser write into the page cache of a root-owned read-only file via\nauthencesn-ESN stray writes.\n\nSet SKBFL_SHARED_FRAG on the destination whenever frag descriptors\nwere actually moved from the source. skb_copy() and skb_copy_expand()\nshare skb_copy_header() too but linearize all paged data into freshly\nallocated head storage and emerge with nr_frags == 0, so\nskb_has_shared_frag() returns false on its own; they need no change.\n\nThe same omission exists in skb_gro_receive() and skb_gro_receive_list().\nThe former moves the incoming skb\u0026apos;s frag descriptors into the\naccumulator\u0026apos;s last sub-skb via two paths (a direct frag-move loop and\nthe head_frag + memcpy path); the latter chains the incoming skb whole\nonto p\u0026apos;s frag_list. Downstream skb_segment() reads only\nskb_shinfo(p)-\u0026gt;flags, and skb_segment_list() reuses each sub-skb\u0026apos;s\nshinfo as the nskb -- both p and lp must carry the marker.\n\nThe same omission also exists in tcp_clone_payload(), which builds an\nMTU probe skb by moving frag descriptors from skbs on sk_write_queue\ninto a freshly allocated nskb. The helper falls into the same family\nand warrants the same fix for consistency; no TCP TX-side in-place\nwriter is currently known to reach a user page through this gap, but\na future consumer depending on the marker would regress silently.\n\nThe same omission exists in skb_segment(): the per-iteration flag\nmerge takes only head_skb\u0026apos;s flag, and the inner switch that rebinds\nfrag_skb to list_skb on head_skb-frags exhaustion does not fold the\nnew frag_skb\u0026apos;s flag into nskb. Fold frag_skb\u0026apos;s flag at both sites\nso segments drawing frags from frag_list members carry the marker.(CVE-2026-43503)",
"id": "OESA-2026-2581",
"modified": "2026-08-06T11:11:31Z",
"published": "2026-06-05T11:11:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2581"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22060"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39833"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68334"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68340"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71094"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71098"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71112"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71123"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71130"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71132"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23074"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23161"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23243"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23272"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23340"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23448"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23473"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31392"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31398"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31421"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31422"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31429"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31430"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31441"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31442"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31446"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31451"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31467"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31469"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31487"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31495"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31496"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31498"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31499"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31505"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31510"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31511"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31512"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31516"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31518"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31525"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31528"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31532"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31540"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31542"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31546"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31555"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31566"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31570"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31590"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31595"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31628"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31630"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31651"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31677"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31699"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31738"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31755"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31771"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31773"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31779"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31781"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43036"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43043"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43079"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43212"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43262"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43345"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43419"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43493"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43503"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-22060",
"CVE-2025-23145",
"CVE-2025-39833",
"CVE-2025-68334",
"CVE-2025-68340",
"CVE-2025-71094",
"CVE-2025-71098",
"CVE-2025-71112",
"CVE-2025-71123",
"CVE-2025-71130",
"CVE-2025-71132",
"CVE-2025-71160",
"CVE-2025-71194",
"CVE-2025-71202",
"CVE-2025-71239",
"CVE-2026-23001",
"CVE-2026-23063",
"CVE-2026-23074",
"CVE-2026-23102",
"CVE-2026-23161",
"CVE-2026-23243",
"CVE-2026-23244",
"CVE-2026-23272",
"CVE-2026-23312",
"CVE-2026-23340",
"CVE-2026-23448",
"CVE-2026-23473",
"CVE-2026-31392",
"CVE-2026-31398",
"CVE-2026-31421",
"CVE-2026-31422",
"CVE-2026-31429",
"CVE-2026-31430",
"CVE-2026-31441",
"CVE-2026-31442",
"CVE-2026-31446",
"CVE-2026-31449",
"CVE-2026-31450",
"CVE-2026-31451",
"CVE-2026-31452",
"CVE-2026-31467",
"CVE-2026-31469",
"CVE-2026-31487",
"CVE-2026-31495",
"CVE-2026-31496",
"CVE-2026-31498",
"CVE-2026-31499",
"CVE-2026-31505",
"CVE-2026-31510",
"CVE-2026-31511",
"CVE-2026-31512",
"CVE-2026-31516",
"CVE-2026-31518",
"CVE-2026-31525",
"CVE-2026-31528",
"CVE-2026-31532",
"CVE-2026-31533",
"CVE-2026-31540",
"CVE-2026-31542",
"CVE-2026-31546",
"CVE-2026-31555",
"CVE-2026-31566",
"CVE-2026-31570",
"CVE-2026-31590",
"CVE-2026-31595",
"CVE-2026-31628",
"CVE-2026-31630",
"CVE-2026-31651",
"CVE-2026-31665",
"CVE-2026-31667",
"CVE-2026-31675",
"CVE-2026-31677",
"CVE-2026-31678",
"CVE-2026-31684",
"CVE-2026-31685",
"CVE-2026-31689",
"CVE-2026-31697",
"CVE-2026-31698",
"CVE-2026-31699",
"CVE-2026-31708",
"CVE-2026-31738",
"CVE-2026-31755",
"CVE-2026-31771",
"CVE-2026-31773",
"CVE-2026-31779",
"CVE-2026-31781",
"CVE-2026-43020",
"CVE-2026-43036",
"CVE-2026-43040",
"CVE-2026-43043",
"CVE-2026-43064",
"CVE-2026-43079",
"CVE-2026-43148",
"CVE-2026-43212",
"CVE-2026-43262",
"CVE-2026-43273",
"CVE-2026-43345",
"CVE-2026-43419",
"CVE-2026-43428",
"CVE-2026-43493",
"CVE-2026-43503"
]
}
OPENSUSE-SU-2026:20416-1
Vulnerability from csaf_opensuse - Published: 2026-03-25 08:49 - Updated: 2026-09-17 17:29SUSE-SU-2026:0962-1
Vulnerability from csaf_suse - Published: 2026-03-23 09:09 - Updated: 2026-09-16 19:10SUSE-SU-2026:1081-1
Vulnerability from csaf_suse - Published: 2026-03-26 13:23 - Updated: 2026-03-26 13:23SUSE-SU-2026:20667-1
Vulnerability from csaf_suse - Published: 2026-03-11 15:14 - Updated: 2026-09-16 19:34SUSE-SU-2026:20720-1
Vulnerability from csaf_suse - Published: 2026-03-11 16:03 - Updated: 2026-09-16 19:34SUSE-SU-2026:20838-1
Vulnerability from csaf_suse - Published: 2026-03-25 08:48 - Updated: 2026-09-16 19:35Sightings
| 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.