Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-71087 (GCVE-0-2025-71087)
Vulnerability from cvelistv5 – Published: 2026-01-13 15:34 – Updated: 2026-06-11 18:44| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
43a3d9ba34c9ca313573201d3f45de5ab3494cec , < ceb8459df28d22c225a82d74c0f725f2a935d194
(git)
Affected: 43a3d9ba34c9ca313573201d3f45de5ab3494cec , < 5bb18bfd505ca1affbca921462c350095a6c798c (git) Affected: 43a3d9ba34c9ca313573201d3f45de5ab3494cec , < d7369dc8dd7cbf5cee3a22610028d847b6f02982 (git) Affected: 43a3d9ba34c9ca313573201d3f45de5ab3494cec , < 18de0e41d69d97fab10b91fecf10ae78a5e43232 (git) Affected: 43a3d9ba34c9ca313573201d3f45de5ab3494cec , < f36de3045d006e6d9be1be495f2ed88d1721e752 (git) Affected: 43a3d9ba34c9ca313573201d3f45de5ab3494cec , < 3095228e1320371e143835d0cebeef1a8a754c66 (git) Affected: 43a3d9ba34c9ca313573201d3f45de5ab3494cec , < 6daa2893f323981c7894c68440823326e93a7d61 (git) |
guessed | |
| Linux | Linux |
Affected:
4.7
Unaffected: 0 , < 4.7 (semver) Unaffected: 5.10.248 , ≤ 5.10.* (semver) Unaffected: 5.15.198 , ≤ 5.15.* (semver) Unaffected: 6.1.160 , ≤ 6.1.* (semver) Unaffected: 6.6.120 , ≤ 6.6.* (semver) Unaffected: 6.12.64 , ≤ 6.12.* (semver) Unaffected: 6.18.4 , ≤ 6.18.* (semver) Unaffected: 6.19 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-71087",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-10T20:41:36.543195Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-11T18:44:14.263Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/iavf/iavf_main.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "ceb8459df28d22c225a82d74c0f725f2a935d194",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "5bb18bfd505ca1affbca921462c350095a6c798c",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "d7369dc8dd7cbf5cee3a22610028d847b6f02982",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "18de0e41d69d97fab10b91fecf10ae78a5e43232",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "f36de3045d006e6d9be1be495f2ed88d1721e752",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "3095228e1320371e143835d0cebeef1a8a754c66",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "6daa2893f323981c7894c68440823326e93a7d61",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/iavf/iavf_main.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.7"
},
{
"lessThan": "4.7",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.248",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.198",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.160",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.4",
"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.248",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.198",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.160",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.120",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.4",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "4.7",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\"i40evf: Allow PF driver to configure RSS\"),\nthe loop upper bounds were:\n i \u003c= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u003c= adapter-\u003erss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u003c=`\naccesses one element past the end.\n\nFix the issues by using `\u003c` instead of `\u003c=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u003effff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:54:29.688Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/ceb8459df28d22c225a82d74c0f725f2a935d194"
},
{
"url": "https://git.kernel.org/stable/c/5bb18bfd505ca1affbca921462c350095a6c798c"
},
{
"url": "https://git.kernel.org/stable/c/d7369dc8dd7cbf5cee3a22610028d847b6f02982"
},
{
"url": "https://git.kernel.org/stable/c/18de0e41d69d97fab10b91fecf10ae78a5e43232"
},
{
"url": "https://git.kernel.org/stable/c/f36de3045d006e6d9be1be495f2ed88d1721e752"
},
{
"url": "https://git.kernel.org/stable/c/3095228e1320371e143835d0cebeef1a8a754c66"
},
{
"url": "https://git.kernel.org/stable/c/6daa2893f323981c7894c68440823326e93a7d61"
}
],
"title": "iavf: fix off-by-one issues in iavf_config_rss_reg()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-71087",
"datePublished": "2026-01-13T15:34:49.691Z",
"dateReserved": "2026-01-13T15:30:19.649Z",
"dateUpdated": "2026-06-11T18:44:14.263Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-71087",
"date": "2026-09-19",
"epss": "0.00134",
"percentile": "0.03264"
},
"microsoft_vex": {
"current_release_date": "2026-02-18T14:16:41.000Z",
"cve": "CVE-2025-71087",
"id": "msrc_CVE-2025-71087",
"initial_release_date": "2026-01-02T00:00:00.000Z",
"product_status:fixed": "1",
"product_status:known_affected": "2",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "iavf: fix off-by-one issues in iavf_config_rss_reg()",
"url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2025-71087.json",
"version": "3"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/iavf/iavf_main.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "ceb8459df28d22c225a82d74c0f725f2a935d194",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "5bb18bfd505ca1affbca921462c350095a6c798c",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "d7369dc8dd7cbf5cee3a22610028d847b6f02982",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "18de0e41d69d97fab10b91fecf10ae78a5e43232",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "f36de3045d006e6d9be1be495f2ed88d1721e752",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "3095228e1320371e143835d0cebeef1a8a754c66",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "6daa2893f323981c7894c68440823326e93a7d61",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/iavf/iavf_main.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.7"
},
{
"lessThan": "4.7",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.248",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.198",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.160",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.4",
"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": "6D7D3E72-3D01-4F26-8FA2-72370332ACC4",
"versionEndExcluding": "5.10.248",
"versionStartIncluding": "4.7.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "82159CAA-B6BA-43C6-85D8-65BDBC175A7E",
"versionEndExcluding": "5.15.198",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C10CC03E-16A9-428A-B449-40D3763E15F6",
"versionEndExcluding": "6.1.160",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "43C3A206-5EEE-417B-AA0F-EF8972E7A9F0",
"versionEndExcluding": "6.6.120",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "32BF4A52-377C-44ED-B5E6-7EA5D896E98B",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DC988EA0-0E32-457A-BF95-89BEB31A227B",
"versionEndExcluding": "6.18.4",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:4.7:-:*:*:*:*:*:*",
"matchCriteriaId": "2F890998-2B89-4DE8-BA87-5B3D9A5E8E11",
"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
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc7:*:*:*:*:*:*",
"matchCriteriaId": "F5DC0CA6-F0AF-4DDF-A882-3DADB9A886A7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc8:*:*:*:*:*:*",
"matchCriteriaId": "EB5B7DFC-C36B-45D8-922C-877569FDDF43",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\"i40evf: Allow PF driver to configure RSS\"),\nthe loop upper bounds were:\n i \u003c= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u003c= adapter-\u003erss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u003c=`\naccesses one element past the end.\n\nFix the issues by using `\u003c` instead of `\u003c=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u003effff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc"
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\niavf: corrige problemas de \u0027off-by-one\u0027 en iavf_config_rss_reg()\n\nExisten errores de \u0027off-by-one\u0027 al configurar la clave hash RSS y la tabla de b\u00fasqueda, causando lecturas fuera de l\u00edmites a la memoria [1] y escrituras fuera de l\u00edmites a los registros del dispositivo.\n\nAntes del commit 43a3d9ba34c9 (\u0027i40evf: Permitir al controlador PF configurar RSS\u0027), los l\u00edmites superiores del bucle eran:\n i \u0026lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nlo cual es seguro ya que el valor es el \u00faltimo \u00edndice v\u00e1lido.\n\nEse commit cambi\u00f3 los l\u00edmites a:\n i \u0026lt;= adapter-\u0026gt;rss_{key,lut}_size / 4\ndonde \u0027rss_{key,lut}_size / 4\u0027 es el n\u00famero de dwords, por lo que el \u00faltimo \u00edndice v\u00e1lido es \u0027(rss_{key,lut}_size / 4) - 1\u0027. Por lo tanto, usar \u0027\u0026lt;=\u0027 accede a un elemento m\u00e1s all\u00e1 del final.\n\nSe corrigen los problemas usando \u0027\u0026lt;\u0027 en lugar de \u0027\u0026lt;=\u0027, asegurando que no excedemos los l\u00edmites.\n\n[1] Informe de KASAN sobre el \u0027off-by-one\u0027 de rss_key_size\n ERROR: KASAN: \u0027slab-out-of-bounds\u0027 en iavf_config_rss+0x619/0x800\n Lectura de tama\u00f1o 4 en la direcci\u00f3n ffff888102c50134 por la tarea kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 No contaminado 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntario)\n Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Cola de trabajo: iavf iavf_watchdog_task\n Traza de llamadas:\n \n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \n\n Asignado por la tarea 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n La direcci\u00f3n con error pertenece al objeto en ffff888102c50100\n el cual pertenece a la cach\u00e9 kmalloc-64 de tama\u00f1o 64\n La direcci\u00f3n con error est\u00e1 ubicada 0 bytes a la derecha de\n la regi\u00f3n asignada de 52 bytes [ffff888102c50100, ffff888102c50134)\n\n La direcci\u00f3n con error pertenece a la p\u00e1gina f\u00edsica:\n p\u00e1gina: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n p\u00e1gina volcada porque: kasan: acceso incorrecto detectado\n\n Estado de la memoria alrededor de la direcci\u00f3n con error:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u0026gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc"
}
],
"id": "CVE-2025-71087",
"lastModified": "2026-06-17T10:03:38.077",
"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"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-71087",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-10T20:41:36.543195Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-01-13T16:16:08.343",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/18de0e41d69d97fab10b91fecf10ae78a5e43232"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3095228e1320371e143835d0cebeef1a8a754c66"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5bb18bfd505ca1affbca921462c350095a6c798c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6daa2893f323981c7894c68440823326e93a7d61"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ceb8459df28d22c225a82d74c0f725f2a935d194"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d7369dc8dd7cbf5cee3a22610028d847b6f02982"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f36de3045d006e6d9be1be495f2ed88d1721e752"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-193"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-28T07:12:21+00:00",
"cve": "CVE-2025-71087",
"id": "CVE-2025-71087",
"initial_release_date": "2025-01-01T00:00:00+00:00",
"product_status:known_affected": "260",
"product_status:known_not_affected": "14",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: iavf: fix off-by-one issues in iavf_config_rss_reg()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-71087.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-71087",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-10T20:41:36.543195Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-11T17:38:32.494Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/iavf/iavf_main.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "ceb8459df28d22c225a82d74c0f725f2a935d194",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "5bb18bfd505ca1affbca921462c350095a6c798c",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "d7369dc8dd7cbf5cee3a22610028d847b6f02982",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "18de0e41d69d97fab10b91fecf10ae78a5e43232",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "f36de3045d006e6d9be1be495f2ed88d1721e752",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "3095228e1320371e143835d0cebeef1a8a754c66",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
},
{
"lessThan": "6daa2893f323981c7894c68440823326e93a7d61",
"status": "affected",
"version": "43a3d9ba34c9ca313573201d3f45de5ab3494cec",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/iavf/iavf_main.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.7"
},
{
"lessThan": "4.7",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.248",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.198",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.160",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.4",
"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.248",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.198",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.160",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.120",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.4",
"versionStartIncluding": "4.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "4.7",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\"i40evf: Allow PF driver to configure RSS\"),\nthe loop upper bounds were:\n i \u003c= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u003c= adapter-\u003erss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u003c=`\naccesses one element past the end.\n\nFix the issues by using `\u003c` instead of `\u003c=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u003effff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:54:29.688Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/ceb8459df28d22c225a82d74c0f725f2a935d194"
},
{
"url": "https://git.kernel.org/stable/c/5bb18bfd505ca1affbca921462c350095a6c798c"
},
{
"url": "https://git.kernel.org/stable/c/d7369dc8dd7cbf5cee3a22610028d847b6f02982"
},
{
"url": "https://git.kernel.org/stable/c/18de0e41d69d97fab10b91fecf10ae78a5e43232"
},
{
"url": "https://git.kernel.org/stable/c/f36de3045d006e6d9be1be495f2ed88d1721e752"
},
{
"url": "https://git.kernel.org/stable/c/3095228e1320371e143835d0cebeef1a8a754c66"
},
{
"url": "https://git.kernel.org/stable/c/6daa2893f323981c7894c68440823326e93a7d61"
}
],
"title": "iavf: fix off-by-one issues in iavf_config_rss_reg()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-71087",
"datePublished": "2026-01-13T15:34:49.691Z",
"dateReserved": "2026-01-13T15:30:19.649Z",
"dateUpdated": "2026-06-11T18:44:14.263Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
GHSA-PWF8-G74P-W24J
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-03-25 21:30In the Linux kernel, the following vulnerability has been resolved:
iavf: fix off-by-one issues in iavf_config_rss_reg()
There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX which is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4
where rss_{key,lut}_size / 4 is the number of dwords, so the last
valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <=
accesses one element past the end.
Fix the issues by using < instead of <=, ensuring we do not exceed
the bounds.
[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30
Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
{
"affected": [],
"aliases": [
"CVE-2025-71087"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T16:16:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\"i40evf: Allow PF driver to configure RSS\"),\nthe loop upper bounds were:\n i \u003c= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u003c= adapter-\u003erss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u003c=`\naccesses one element past the end.\n\nFix the issues by using `\u003c` instead of `\u003c=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u003effff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc",
"id": "GHSA-pwf8-g74p-w24j",
"modified": "2026-03-25T21:30:22Z",
"published": "2026-01-13T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18de0e41d69d97fab10b91fecf10ae78a5e43232"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3095228e1320371e143835d0cebeef1a8a754c66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5bb18bfd505ca1affbca921462c350095a6c798c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6daa2893f323981c7894c68440823326e93a7d61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ceb8459df28d22c225a82d74c0f725f2a935d194"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7369dc8dd7cbf5cee3a22610028d847b6f02982"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f36de3045d006e6d9be1be495f2ed88d1721e752"
}
],
"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"
}
]
}
MSRC_CVE-2025-71087
Vulnerability from csaf_microsoft - Published: 2026-01-02 00:00 - Updated: 2026-02-18 14:16OESA-2026-1275 (CVE-2022-49157)
Vulnerability from osv_openeuler – Published: 2026-01-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix premature hw access after PCI error
After a recoverable PCI error has been detected and recovered, qla driver needs to check to see if the error condition still persist and/or wait for the OS to give the resume signal.
Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440 qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: Call Trace: Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80 Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80 Sep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90 Sep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0 Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240 Sep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0 Sep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360 .. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI disconnect. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to capture FW dump Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0, waited 5221 msecs Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio enabled returning. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5 mb[0-3]=0xffff 0xffff 0xffff 0xffff
In the Linux kernel, the following vulnerability has been resolved:
md/raid0, raid10: Don't set discard sectors for request queue
It should use disk_stack_limits to get a proper max_discard_sectors rather than setting a value by stack drivers.
And there is a bug. If all member disks are rotational devices, raid0/raid10 set max_discard_sectors. So the member devices are not ssd/nvme, but raid0/raid10 export the wrong value. It reports warning messages in function __blkdev_issue_discard when mkfs.xfs like this:
[ 4616.022599] ------------[ cut here ]------------ [ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0 [ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0 [ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff <0f> 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7 [ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246 [ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080 [ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080 [ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000 [ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000 [ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080 [ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000 [ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0 [ 4616.236689] Call Trace: [ 4616.239428] blkdev_issue_discard+0x52/0xb0 [ 4616.244108] blkdev_common_ioctl+0x43c/0xa00 [ 4616.248883] blkdev_ioctl+0x116/0x280 [ 4616.252977] __x64_sys_ioctl+0x8a/0xc0 [ 4616.257163] do_syscall_64+0x5c/0x90 [ 4616.261164] ? handle_mm_fault+0xc5/0x2a0 [ 4616.265652] ? do_user_addr_fault+0x1d8/0x690 [ 4616.270527] ? do_syscall_64+0x69/0x90 [ 4616.274717] ? exc_page_fault+0x62/0x150 [ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4616.284748] RIP: 0033:0x7f9a55398c6b(CVE-2022-50583)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate index root when initialize NTFS security
This enhances the sanity check for $SDH and $SII while initializing NTFS security, guarantees these index root are legit.
[ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320 [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 162.462609] Call Trace: [ 162.462954] <TASK> [ 162.463276] dump_stack_lvl+0x49/0x63 [ 162.463822] print_report.cold+0xf5/0x689 [ 162.464608] ? unwind_get_return_address+0x3a/0x60 [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.466975] kasan_report+0xa7/0x130 [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0 [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.468536] __asan_load2+0x68/0x90 [ 162.468923] hdr_find_e.isra.0+0x10c/0x320 [ 162.469282] ? cmp_uints+0xe0/0xe0 [ 162.469557] ? cmp_sdh+0x90/0x90 [ 162.469864] ? ni_find_attr+0x214/0x300 [ 162.470217] ? ni_load_mi+0x80/0x80 [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.470931] ? ntfs_bread_run+0x190/0x190 [ 162.471307] ? indx_get_root+0xe4/0x190 [ 162.471556] ? indx_get_root+0x140/0x190 [ 162.471833] ? indx_init+0x1e0/0x1e0 [ 162.472069] ? fnd_clear+0x115/0x140 [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100 [ 162.472731] indx_find+0x184/0x470 [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0 [ 162.474704] ? do_syscall_64+0x3b/0x90 [ 162.474962] dir_search_u+0x196/0x2f0 [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450 [ 162.475661] ? ntfs_security_init+0x3d6/0x440 [ 162.475906] ? is_sd_valid+0x180/0x180 [ 162.476191] ntfs_extend_init+0x13f/0x2c0 [ 162.476496] ? ntfs_fix_post_read+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfs_fill_super+0x11e0/0x1b50 [ 162.477709] ? put_ntfs+0x1d0/0x1d0 [ 162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? set_blocksize+0x95/0x150 [ 162.478538] get_tree_bdev+0x232/0x370 [ 162.478789] ? put_ntfs+0x1d0/0x1d0 [ 162.479038] ntfs_fs_get_tree+0x15/0x20 [ 162.479374] vfs_get_tree+0x4c/0x130 [ 162.479729] path_mount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finish_automount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmem_cache_free+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] do_mount+0xd6/0xf0 [ 162.483264] ? path_mount+0xfe0/0xfe0 [ 162.484782] ? __kasan_check_write+0x14/0x20 [ 162.485593] __x64_sys_mount+0xca/0x110 [ 162.486024] do_syscall_64+0x3b/0x90 [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.487141] RIP: 0033:0x7f9d374e948a [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0 [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020 [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [ 162.493644] </TASK> [ 162.493908] [ 162.494214] The buggy address belongs to the physical page: [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 0 ---truncated---(CVE-2022-50737)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL
OPDESC() simply indexes into nfsd4_ops[] by the op's operation number, without range checking that value. It assumes callers are careful to avoid calling it with an out-of-bounds opnum value.
nfsd4_decode_compound() is not so careful, and can invoke OPDESC() with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end of nfsd4_ops[].(CVE-2023-53680)
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix session state check in reconnect to avoid use-after-free issue
Don't collect exiting session in smb2_reconnect_server(), because it will be released soon.
Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list.(CVE-2023-53794)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP
Fixes OOPS on boards with ANX9805 DP encoders.(CVE-2023-54263)
In the Linux kernel, the following vulnerability has been resolved:
jfs: add sanity check for agwidth in dbMount
The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG.
To avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Prevent division by zero
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37768)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free in cifs_fill_dirent
There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning.
================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975
CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK>
Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30
Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================
POC is available in the link [1].
The problem triggering process is as follows:
Process 1 Process 2
---truncated---(CVE-2025-38051)
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio as follow:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast.(CVE-2025-38102)
In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()
Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor.
Update all references to member element desc[0] to rpt_desc.
Add test to verify bLength and bNumDescriptors values are valid.
Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault.
Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors.(CVE-2025-38103)
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds read/write access
When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.
Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38111)
In the Linux kernel, the following vulnerability has been resolved:
software node: Correct a OOB check in software_node_get_reference_args()
software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property.
Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)
In the Linux kernel, the following vulnerability has been resolved:
jfs: upper bound check of tree index in dbAllocAG
When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.(CVE-2025-38697)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix null pointer access
Writing a string without delimiters (' ', '\n', '\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference.(CVE-2025-38705)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplus_fill_super() assumes that the attributes file is not yet created, which later results in hitting BUG_ON() when hfsplus_create_attributes_file() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc():
[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfxx64sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---(CVE-2025-38713)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
The hfsplus_bnode_read() method can trigger the issue:
[ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] <TASK> [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0 [ 174.854305][ T9784] print_report+0xd0/0x660 [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610 [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854337][ T9784] kasan_report+0xc6/0x100 [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360 [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380 [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10 [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0 [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310 [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0 [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0 [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10 [ 174.854427][ T9784] ? __pfxhfsplusdelete_attr+0x10/0x10 [ 174.854436][ T9784] ? asan_memset+0x23/0x50 [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320 [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10 [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0 [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0 [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10 [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10 [ 174.854525][ T9784] ? down_write+0x148/0x200 [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10 [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0 [ 174.854549][ T9784] do_unlinkat+0x490/0x670 [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10 [ 174.854565][ T9784] ? __might_fault+0xbc/0x130 [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550 [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110 [ 174.854592][ T9784] do_syscall_64+0xc9/0x480 [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] </TASK> [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasan_save_stack+0x20/0x40 [ 174.880082][ T9784] kasan_save_track+0x14/0x30 [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0 [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550 [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890 [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10 [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520 [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3 ---truncated---(CVE-2025-38714)
In the Linux kernel, the following vulnerability has been resolved:
fs/buffer: fix use-after-free when call bh_read() helper
There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ>
Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer
wait_on_buffer(bh);--> return will return to caller
put_bh
--> trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun.
If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch().(CVE-2025-39691)
In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()
A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.
watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]
The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.
The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects.
As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.(CVE-2025-39737)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: use array_index_nospec with indices that come from guest
min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.(CVE-2025-39823)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix OOB read/write in network-coding decode
batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.
Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.(CVE-2025-39839)
In the Linux kernel, the following vulnerability has been resolved:
um: virtio_uml: Fix use-after-free after put_device in probe
When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.(CVE-2025-39951)
In the Linux kernel, the following vulnerability has been resolved:
i40e: add max boundary check for VF filters
There is no check for max filters that VF can request. Add it.(CVE-2025-39968)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix Use-after-free in validation
Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.(CVE-2025-40111)
In the Linux kernel, the following vulnerability has been resolved:
pid: Add a judgment for ns null in pid_nr_ns
__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {
Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.
For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Do not sleep in atomic context
sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.(CVE-2025-40259)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.
Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...(CVE-2025-68229)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to:
1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.
Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)
A use-after-free vulnerability exists in the mlxsw spectrum multicast route component of Linux Kernel. The vulnerability occurs when updating multicast route statistics, where an instance of list entry deletion during route replace was missed from mutex protection, potentially leading to use-after-free.(CVE-2025-68800)
A reference counting management vulnerability exists in the mlxsw: spectrum_router driver component of the Linux kernel. The driver stores a pointer to a neighbour object without properly holding a reference to it. A reference is only taken when the neighbour is used by a nexthop. This inconsistent reference counting scheme can lead to a situation where, under specific conditions (e.g., during network device event handling), the driver attempts to access a neighbour object that has already been freed, triggering a use-after-free error. An attacker could potentially exploit this vulnerability to cause a kernel crash, thereby affecting system availability.(CVE-2025-68801)
An off-by-one vulnerability exists in the Intel Ethernet Virtual Function (iavf) driver of the Linux kernel. The flaw resides in the iavf_config_rss_reg() function. When configuring the Receive Side Scaling (RSS) hash key and lookup table, incorrect loop boundary conditions (using <= instead of <) lead to out-of-bounds reads from allocated memory and potential out-of-bounds writes to device registers. An attacker could potentially exploit this vulnerability to cause kernel information disclosure, system instability, or crashes.(CVE-2025-71087)
In the Linux kernel, a buffer overflow vulnerability exists in the e1000 network driver's e1000_tbi_should_accept() function. The function reads the last byte of the frame via 'data[length - 1]' to evaluate the TBI (Tunnel Bypass Identifier) workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq). The root cause is that the TBI check unconditionally dereferences the last byte without validating the reported length first. The fix rejects the frame early if the length is zero or exceeds adapter->rx_buffer_len, preserving the TBI workaround semantics for valid frames and preventing touching memory beyond the RX buffer.(CVE-2025-71093)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in update_target_expiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 </IRQ>
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---(CVE-2025-71104)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Do not register unsupported perf events
Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:
------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:
# perf record -e synthetic:futex_wait Error: The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.
Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.(CVE-2025-71125)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"perf-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-299.0.0.202.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"perf-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-299.0.0.202.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix premature hw access after PCI error\n\nAfter a recoverable PCI error has been detected and recovered, qla driver\nneeds to check to see if the error condition still persist and/or wait\nfor the OS to give the resume signal.\n\nSep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440\nqla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx]\nSep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60\n[qla2xxx]\nSep 8 22:26:03 localhost kernel: Call Trace:\nSep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx]\nSep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160\n[qla2xxx]\nSep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx]\nSep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120\n[qla2xxx]\nSep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80\nSep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80\nSep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90\nSep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0\nSep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240\nSep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0\nSep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360\n..\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI\ndisconnect.\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22:\nqla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to\ncapture FW dump\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0,\nwaited 5221 msecs\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio\nenabled returning.\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX\nCommand timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5\nmb[0-3]=[0xffff 0xffff 0xffff 0xffff](CVE-2022-49157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid0, raid10: Don\u0026apos;t set discard sectors for request queue\n\nIt should use disk_stack_limits to get a proper max_discard_sectors\nrather than setting a value by stack drivers.\n\nAnd there is a bug. If all member disks are rotational devices,\nraid0/raid10 set max_discard_sectors. So the member devices are\nnot ssd/nvme, but raid0/raid10 export the wrong value. It reports\nwarning messages in function __blkdev_issue_discard when mkfs.xfs\nlike this:\n\n[ 4616.022599] ------------[ cut here ]------------\n[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0\n[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0\n[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff \u0026lt;0f\u0026gt; 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7\n[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246\n[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080\n[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080\n[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000\n[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000\n[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080\n[ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000\n[ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0\n[ 4616.236689] Call Trace:\n[ 4616.239428] blkdev_issue_discard+0x52/0xb0\n[ 4616.244108] blkdev_common_ioctl+0x43c/0xa00\n[ 4616.248883] blkdev_ioctl+0x116/0x280\n[ 4616.252977] __x64_sys_ioctl+0x8a/0xc0\n[ 4616.257163] do_syscall_64+0x5c/0x90\n[ 4616.261164] ? handle_mm_fault+0xc5/0x2a0\n[ 4616.265652] ? do_user_addr_fault+0x1d8/0x690\n[ 4616.270527] ? do_syscall_64+0x69/0x90\n[ 4616.274717] ? exc_page_fault+0x62/0x150\n[ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 4616.284748] RIP: 0033:0x7f9a55398c6b(CVE-2022-50583)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate index root when initialize NTFS security\n\nThis enhances the sanity check for $SDH and $SII while initializing NTFS\nsecurity, guarantees these index root are legit.\n\n[ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320\n[ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243\n[ 162.460851]\n[ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42\n[ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[ 162.462609] Call Trace:\n[ 162.462954] \u0026lt;TASK\u0026gt;\n[ 162.463276] dump_stack_lvl+0x49/0x63\n[ 162.463822] print_report.cold+0xf5/0x689\n[ 162.464608] ? unwind_get_return_address+0x3a/0x60\n[ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320\n[ 162.466975] kasan_report+0xa7/0x130\n[ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0\n[ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320\n[ 162.468536] __asan_load2+0x68/0x90\n[ 162.468923] hdr_find_e.isra.0+0x10c/0x320\n[ 162.469282] ? cmp_uints+0xe0/0xe0\n[ 162.469557] ? cmp_sdh+0x90/0x90\n[ 162.469864] ? ni_find_attr+0x214/0x300\n[ 162.470217] ? ni_load_mi+0x80/0x80\n[ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 162.470931] ? ntfs_bread_run+0x190/0x190\n[ 162.471307] ? indx_get_root+0xe4/0x190\n[ 162.471556] ? indx_get_root+0x140/0x190\n[ 162.471833] ? indx_init+0x1e0/0x1e0\n[ 162.472069] ? fnd_clear+0x115/0x140\n[ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100\n[ 162.472731] indx_find+0x184/0x470\n[ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0\n[ 162.474429] ? indx_find_buffer+0x2d0/0x2d0\n[ 162.474704] ? do_syscall_64+0x3b/0x90\n[ 162.474962] dir_search_u+0x196/0x2f0\n[ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450\n[ 162.475661] ? ntfs_security_init+0x3d6/0x440\n[ 162.475906] ? is_sd_valid+0x180/0x180\n[ 162.476191] ntfs_extend_init+0x13f/0x2c0\n[ 162.476496] ? ntfs_fix_post_read+0x130/0x130\n[ 162.476861] ? iput.part.0+0x286/0x320\n[ 162.477325] ntfs_fill_super+0x11e0/0x1b50\n[ 162.477709] ? put_ntfs+0x1d0/0x1d0\n[ 162.477970] ? vsprintf+0x20/0x20\n[ 162.478258] ? set_blocksize+0x95/0x150\n[ 162.478538] get_tree_bdev+0x232/0x370\n[ 162.478789] ? put_ntfs+0x1d0/0x1d0\n[ 162.479038] ntfs_fs_get_tree+0x15/0x20\n[ 162.479374] vfs_get_tree+0x4c/0x130\n[ 162.479729] path_mount+0x654/0xfe0\n[ 162.480124] ? putname+0x80/0xa0\n[ 162.480484] ? finish_automount+0x2e0/0x2e0\n[ 162.480894] ? putname+0x80/0xa0\n[ 162.481467] ? kmem_cache_free+0x1c4/0x440\n[ 162.482280] ? putname+0x80/0xa0\n[ 162.482714] do_mount+0xd6/0xf0\n[ 162.483264] ? path_mount+0xfe0/0xfe0\n[ 162.484782] ? __kasan_check_write+0x14/0x20\n[ 162.485593] __x64_sys_mount+0xca/0x110\n[ 162.486024] do_syscall_64+0x3b/0x90\n[ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 162.487141] RIP: 0033:0x7f9d374e948a\n[ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5\n[ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a\n[ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0\n[ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020\n[ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0\n[ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff\n[ 162.493644] \u0026lt;/TASK\u0026gt;\n[ 162.493908]\n[ 162.494214] The buggy address belongs to the physical page:\n[ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc\n[ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n[ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000\n[ 162.498928] raw: 0000000000000000 0000000000240000 0\n---truncated---(CVE-2022-50737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Avoid calling OPDESC() with ops-\u0026gt;opnum == OP_ILLEGAL\n\nOPDESC() simply indexes into nfsd4_ops[] by the op\u0026apos;s operation\nnumber, without range checking that value. It assumes callers are\ncareful to avoid calling it with an out-of-bounds opnum value.\n\nnfsd4_decode_compound() is not so careful, and can invoke OPDESC()\nwith opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end\nof nfsd4_ops[].(CVE-2023-53680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix session state check in reconnect to avoid use-after-free issue\n\nDon\u0026apos;t collect exiting session in smb2_reconnect_server(), because it\nwill be released soon.\n\nNote that the exiting session will stay in server-\u0026gt;smb_ses_list until\nit complete the cifs_free_ipc() and logoff() and then delete itself\nfrom the list.(CVE-2023-53794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP\n\nFixes OOPS on boards with ANX9805 DP encoders.(CVE-2023-54263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add sanity check for agwidth in dbMount\n\nThe width in dmapctl of the AG is zero, it trigger a divide error when\ncalculating the control page level in dbAllocAG.\n\nTo avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37768)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix use-after-free in cifs_fill_dirent\n\nThere is a race condition in the readdir concurrency process, which may\naccess the rsp buffer after it has been released, triggering the\nfollowing KASAN warning.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]\n Read of size 4 at addr ffff8880099b819c by task a.out/342975\n\n CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x53/0x70\n print_report+0xce/0x640\n kasan_report+0xb8/0xf0\n cifs_fill_dirent+0xb03/0xb60 [cifs]\n cifs_readdir+0x12cb/0x3190 [cifs]\n iterate_dir+0x1a1/0x520\n __x64_sys_getdents+0x134/0x220\n do_syscall_64+0x4b/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f996f64b9f9\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89\n f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01\n f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8\n RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e\n RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88\n R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 408:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n __kasan_slab_alloc+0x6e/0x70\n kmem_cache_alloc_noprof+0x117/0x3d0\n mempool_alloc_noprof+0xf2/0x2c0\n cifs_buf_get+0x36/0x80 [cifs]\n allocate_buffers+0x1d2/0x330 [cifs]\n cifs_demultiplex_thread+0x22b/0x2690 [cifs]\n kthread+0x394/0x720\n ret_from_fork+0x34/0x70\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 342979:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x37/0x50\n kmem_cache_free+0x2b8/0x500\n cifs_buf_release+0x3c/0x70 [cifs]\n cifs_readdir+0x1c97/0x3190 [cifs]\n iterate_dir+0x1a1/0x520\n __x64_sys_getdents64+0x134/0x220\n do_syscall_64+0x4b/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n The buggy address belongs to the object at ffff8880099b8000\n which belongs to the cache cifs_request of size 16588\n The buggy address is located 412 bytes inside of\n freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8\n head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n anon flags: 0x80000000000040(head|node=0|zone=1)\n page_type: f5(slab)\n raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff\n head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n \u0026gt;ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ^\n ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ==================================================================\n\nPOC is available in the link [1].\n\nThe problem triggering process is as follows:\n\nProcess 1 Process 2\n-----------------------------------\n---truncated---(CVE-2025-38051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n Modules linked in:\n CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n RIP: 0010:try_grab_folio+0x106/0x130\n Call Trace:\n \u0026lt;TASK\u0026gt;\n follow_huge_pmd+0x240/0x8e0\n follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n follow_page_mask+0x1c2/0x1f0\n __get_user_pages+0x176/0x950\n __gup_longterm_locked+0x15b/0x1060\n ? gup_fast+0x120/0x1f0\n gup_fast_fallback+0x17e/0x230\n get_user_pages_fast+0x5f/0x80\n vmci_host_unlocked_ioctl+0x21c/0xf80\n RIP: 0033:0x54d2cd\n ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context-\u0026gt;notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, \u0026amp;context-\u0026gt;notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd // update \u0026amp;context-\u0026gt;notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context-\u0026gt;notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.(CVE-2025-38102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()\n\nUpdate struct hid_descriptor to better reflect the mandatory and\noptional parts of the HID Descriptor as per USB HID 1.11 specification.\nNote: the kernel currently does not parse any optional HID class\ndescriptors, only the mandatory report descriptor.\n\nUpdate all references to member element desc[0] to rpt_desc.\n\nAdd test to verify bLength and bNumDescriptors values are valid.\n\nReplace the for loop with direct access to the mandatory HID class\ndescriptor member for the report descriptor. This eliminates the\npossibility of getting an out-of-bounds fault.\n\nAdd a warning message if the HID descriptor contains any unsupported\noptional HID class descriptors.(CVE-2025-38103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via mdiobus, there is no verification of\nparameters passed to the ioctl and it accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoftware node: Correct a OOB check in software_node_get_reference_args()\n\nsoftware_node_get_reference_args() wants to get @index-th element, so\nthe property value requires at least \u0026apos;(index + 1) * sizeof(*ref)\u0026apos; bytes\nbut that can not be guaranteed by current OOB check, and may cause OOB\nfor malformed property.\n\nFix by using as OOB check \u0026apos;((index + 1) * sizeof(*ref) \u0026gt; prop-\u0026gt;length)\u0026apos;.(CVE-2025-38342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: upper bound check of tree index in dbAllocAG\n\nWhen computing the tree index in dbAllocAG, we never check if we are\nout of bounds realative to the size of the stree.\nThis could happen in a scenario where the filesystem metadata are\ncorrupted.(CVE-2025-38697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: fix null pointer access\n\nWriting a string without delimiters (\u0026apos; \u0026apos;, \u0026apos;\\n\u0026apos;, \u0026apos;\\0\u0026apos;) to the under\ngpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile\nwill result in a null pointer dereference.(CVE-2025-38705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: don\u0026apos;t use BUG_ON() in hfsplus_create_attributes_file()\n\nWhen the volume header contains erroneous values that do not reflect\nthe actual state of the filesystem, hfsplus_fill_super() assumes that\nthe attributes file is not yet created, which later results in hitting\nBUG_ON() when hfsplus_create_attributes_file() is called. Replace this\nBUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nThe hfsplus_readdir() method is capable to crash by calling\nhfsplus_uni2asc():\n\n[ 667.121659][ T9805] ==================================================================\n[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10\n[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805\n[ 667.124578][ T9805]\n[ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)\n[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 667.124890][ T9805] Call Trace:\n[ 667.124893][ T9805] \u0026lt;TASK\u0026gt;\n[ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0\n[ 667.124911][ T9805] print_report+0xd0/0x660\n[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610\n[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180\n[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124942][ T9805] kasan_report+0xc6/0x100\n[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10\n[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360\n[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0\n[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10\n[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0\n[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0\n[ 667.125022][ T9805] ? lock_acquire+0x30/0x80\n[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0\n[ 667.125044][ T9805] ? putname+0x154/0x1a0\n[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10\n[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0\n[ 667.125069][ T9805] iterate_dir+0x296/0xb20\n[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10\n[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200\n[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10\n[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0\n[ 667.125143][ T9805] do_syscall_64+0xc9/0x480\n[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9\n[ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48\n[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9\n[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9\n[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004\n[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110\n[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260\n[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 667.125207][ T9805] \u0026lt;/TASK\u0026gt;\n[ 667.125210][ T9805]\n[ 667.145632][ T9805] Allocated by task 9805:\n[ 667.145991][ T9805] kasan_save_stack+0x20/0x40\n[ 667.146352][ T9805] kasan_save_track+0x14/0x30\n[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0\n[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550\n[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0\n[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0\n[ 667.148174][ T9805] iterate_dir+0x296/0xb20\n[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.148937][ T9805] do_syscall_64+0xc9/0x480\n[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.149809][ T9805]\n[ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000\n[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048\n[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of\n[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)\n[ 667.1\n---truncated---(CVE-2025-38713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()\n\nThe hfsplus_bnode_read() method can trigger the issue:\n\n[ 174.852007][ T9784] ==================================================================\n[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360\n[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784\n[ 174.854059][ T9784]\n[ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)\n[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 174.854286][ T9784] Call Trace:\n[ 174.854289][ T9784] \u0026lt;TASK\u0026gt;\n[ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0\n[ 174.854305][ T9784] print_report+0xd0/0x660\n[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610\n[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180\n[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854337][ T9784] kasan_report+0xc6/0x100\n[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360\n[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380\n[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10\n[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0\n[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310\n[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0\n[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0\n[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10\n[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10\n[ 174.854436][ T9784] ? __asan_memset+0x23/0x50\n[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320\n[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10\n[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0\n[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0\n[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10\n[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0\n[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10\n[ 174.854525][ T9784] ? down_write+0x148/0x200\n[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10\n[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0\n[ 174.854549][ T9784] do_unlinkat+0x490/0x670\n[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10\n[ 174.854565][ T9784] ? __might_fault+0xbc/0x130\n[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550\n[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110\n[ 174.854592][ T9784] do_syscall_64+0xc9/0x480\n[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167\n[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08\n[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057\n[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167\n[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50\n[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40\n[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0\n[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 174.854658][ T9784] \u0026lt;/TASK\u0026gt;\n[ 174.854661][ T9784]\n[ 174.879281][ T9784] Allocated by task 9784:\n[ 174.879664][ T9784] kasan_save_stack+0x20/0x40\n[ 174.880082][ T9784] kasan_save_track+0x14/0x30\n[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0\n[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550\n[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890\n[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10\n[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520\n[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3\n---truncated---(CVE-2025-38714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/buffer: fix use-after-free when call bh_read() helper\n\nThere\u0026apos;s issue as follows:\nBUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110\nRead of size 8 at addr ffffc9000168f7f8 by task swapper/3/0\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x55/0x70\n print_address_description.constprop.0+0x2c/0x390\n print_report+0xb4/0x270\n kasan_report+0xb8/0xf0\n end_buffer_read_sync+0xe3/0x110\n end_bio_bh_io_sync+0x56/0x80\n blk_update_request+0x30a/0x720\n scsi_end_request+0x51/0x2b0\n scsi_io_completion+0xe3/0x480\n ? scsi_device_unbusy+0x11e/0x160\n blk_complete_reqs+0x7b/0x90\n handle_softirqs+0xef/0x370\n irq_exit_rcu+0xa5/0xd0\n sysvec_apic_timer_interrupt+0x6e/0x90\n \u0026lt;/IRQ\u0026gt;\n\n Above issue happens when do ntfs3 filesystem mount, issue may happens\n as follows:\n mount IRQ\nntfs_fill_super\n read_cache_page\n do_read_cache_folio\n filemap_read_folio\n mpage_read_folio\n\t do_mpage_readpage\n\t ntfs_get_block_vbo\n\t bh_read\n\t submit_bh\n\t wait_on_buffer(bh);\n\t blk_complete_reqs\n\t\t\t\t scsi_io_completion\n\t\t\t\t scsi_end_request\n\t\t\t\t blk_update_request\n\t\t\t\t end_bio_bh_io_sync\n\t\t\t\t\t end_buffer_read_sync\n\t\t\t\t\t __end_buffer_read_notouch\n\t\t\t\t\t unlock_buffer\n\n wait_on_buffer(bh);--\u0026gt; return will return to caller\n\n\t\t\t\t\t put_bh\n\t\t\t\t\t --\u0026gt; trigger stack-out-of-bounds\nIn the mpage_read_folio() function, the stack variable \u0026apos;map_bh\u0026apos; is\npassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and\nwait_on_buffer() returns to continue processing, the stack variable\nis likely to be reclaimed. Consequently, during the end_buffer_read_sync()\nprocess, calling put_bh() may result in stack overrun.\n\nIf the bh is not allocated on the stack, it belongs to a folio. Freeing\na buffer head which belongs to a folio is done by drop_buffers() which\nwill fail to free buffers which are still locked. So it is safe to call\nput_bh() before __end_buffer_read_notouch().(CVE-2025-39691)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel. Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects. The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue. In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn\u0026apos;t really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen. So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.(CVE-2025-39737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: use array_index_nospec with indices that come from guest\n\nmin and dest_id are guest-controlled indices. Using array_index_nospec()\nafter the bounds checks clamps these values to mitigate speculative execution\nside-channels.(CVE-2025-39823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix OOB read/write in network-coding decode\n\nbatadv_nc_skb_decode_packet() trusts coded_len and checks only against\nskb-\u0026gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing\npayload headroom, and the source skb length is not verified, allowing an\nout-of-bounds read and a small out-of-bounds write.\n\nValidate that coded_len fits within the payload area of both destination\nand source sk_buffs before XORing.(CVE-2025-39839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: virtio_uml: Fix use-after-free after put_device in probe\n\nWhen register_virtio_device() fails in virtio_uml_probe(),\nthe code sets vu_dev-\u0026gt;registered = 1 even though\nthe device was not successfully registered.\nThis can lead to use-after-free or other issues.(CVE-2025-39951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add max boundary check for VF filters\n\nThere is no check for max filters that VF can request. Add it.(CVE-2025-39968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix Use-after-free in validation\n\nNodes stored in the validation duplicates hashtable come from an arena\nallocator that is cleared at the end of vmw_execbuf_process. All nodes\nare expected to be cleared in vmw_validation_drop_ht but this node escaped\nbecause its resource was destroyed prematurely.(CVE-2025-40111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npid: Add a judgment for ns null in pid_nr_ns\n\n__task_pid_nr_ns\n ns = task_active_pid_ns(current);\n pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);\n if (pid \u0026amp;\u0026amp; ns-\u0026gt;level \u0026lt;= pid-\u0026gt;level) {\n\nSometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.\n\nFor example:\n\tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n\tMem abort info:\n\tESR = 0x0000000096000007\n\tEC = 0x25: DABT (current EL), IL = 32 bits\n\tSET = 0, FnV = 0\n\tEA = 0, S1PTW = 0\n\tFSC = 0x07: level 3 translation fault\n\tData abort info:\n\tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n\tCM = 0, WnR = 0, TnD = 0, TagAccess = 0\n\tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000\n\t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000\n\tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n\tpc : __task_pid_nr_ns+0x74/0xd0\n\tlr : __task_pid_nr_ns+0x24/0xd0\n\tsp : ffffffc08001bd10\n\tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001\n\tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31\n\tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0\n\tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000\n\tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc\n\tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800\n\tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001\n\tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449\n\tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc\n\tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0\n\tCall trace:\n\t__task_pid_nr_ns+0x74/0xd0\n\t...\n\t__handle_irq_event_percpu+0xd4/0x284\n\thandle_irq_event+0x48/0xb0\n\thandle_fasteoi_irq+0x160/0x2d8\n\tgeneric_handle_domain_irq+0x44/0x60\n\tgic_handle_irq+0x4c/0x114\n\tcall_on_irq_stack+0x3c/0x74\n\tdo_interrupt_handler+0x4c/0x84\n\tel1_interrupt+0x34/0x58\n\tel1h_64_irq_handler+0x18/0x24\n\tel1h_64_irq+0x68/0x6c\n\taccount_kernel_stack+0x60/0x144\n\texit_task_stack_account+0x1c/0x80\n\tdo_exit+0x7e4/0xaf8\n\t...\n\tget_signal+0x7bc/0x8d8\n\tdo_notify_resume+0x128/0x828\n\tel0_svc+0x6c/0x70\n\tel0t_64_sync_handler+0x68/0xbc\n\tel0t_64_sync+0x1a8/0x1ac\n\tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)\n\t---[ end trace 0000000000000000 ]---\n\tKernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Do not sleep in atomic context\n\nsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may\nsleep. Hence, call sg_finish_rem_req() with interrupts enabled instead\nof disabled.(CVE-2025-40259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()\n\nIf the allocation of tl_hba-\u0026gt;sh fails in tcm_loop_driver_probe() and we\nattempt to dereference it in tcm_loop_tpg_address_show() we will get a\nsegfault, see below for an example. So, check tl_hba-\u0026gt;sh before\ndereferencing it.\n\n Unable to allocate struct scsi_host\n BUG: kernel NULL pointer dereference, address: 0000000000000194\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1\n Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024\n RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]\n...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n configfs_read_iter+0x12d/0x1d0 [configfs]\n vfs_read+0x1b5/0x300\n ksys_read+0x6f/0xf0\n...(CVE-2025-68229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Protect regulator_supply_alias_list with regulator_list_mutex\n\nregulator_supply_alias_list was accessed without any locking in\nregulator_supply_alias(), regulator_register_supply_alias(), and\nregulator_unregister_supply_alias(). Concurrent registration,\nunregistration and lookups can race, leading to:\n\n1 use-after-free if an alias entry is removed while being read,\n2 duplicate entries when two threads register the same alias,\n3 inconsistent alias mappings observed by consumers.\n\nProtect all traversals, insertions and deletions on\nregulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)\n\nA use-after-free vulnerability exists in the mlxsw spectrum multicast route component of Linux Kernel. The vulnerability occurs when updating multicast route statistics, where an instance of list entry deletion during route replace was missed from mutex protection, potentially leading to use-after-free.(CVE-2025-68800)\n\nA reference counting management vulnerability exists in the mlxsw: spectrum_router driver component of the Linux kernel. The driver stores a pointer to a neighbour object without properly holding a reference to it. A reference is only taken when the neighbour is used by a nexthop. This inconsistent reference counting scheme can lead to a situation where, under specific conditions (e.g., during network device event handling), the driver attempts to access a neighbour object that has already been freed, triggering a use-after-free error. An attacker could potentially exploit this vulnerability to cause a kernel crash, thereby affecting system availability.(CVE-2025-68801)\n\nAn off-by-one vulnerability exists in the Intel Ethernet Virtual Function (iavf) driver of the Linux kernel. The flaw resides in the `iavf_config_rss_reg()` function. When configuring the Receive Side Scaling (RSS) hash key and lookup table, incorrect loop boundary conditions (using `\u0026lt;=` instead of `\u0026lt;`) lead to out-of-bounds reads from allocated memory and potential out-of-bounds writes to device registers. An attacker could potentially exploit this vulnerability to cause kernel information disclosure, system instability, or crashes.(CVE-2025-71087)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the e1000 network driver\u0026apos;s e1000_tbi_should_accept() function. The function reads the last byte of the frame via \u0026apos;data[length - 1]\u0026apos; to evaluate the TBI (Tunnel Bypass Identifier) workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq). The root cause is that the TBI check unconditionally dereferences the last byte without validating the reported length first. The fix rejects the frame early if the length is zero or exceeds adapter-\u0026gt;rx_buffer_len, preserving the TBI workaround semantics for valid frames and preventing touching memory beyond the RX buffer.(CVE-2025-71093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest\u0026apos;s APIC timer in periodic\nmode, set the expiration to \u0026quot;now\u0026quot; if the target expiration is in the past\n(similar to what is done in update_target_expiration()). Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over. In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active. As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past. As a result, the delta\nmay be calculated as a negative value. When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming. I.e. the large\nvalue will exceed the VMX Preemption Timer\u0026apos;s maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM\u0026apos;s request for an expiration in the past and\nimmediately re-invokes KVM\u0026apos;s callback after reprogramming. And because\nthe interrupt handler runs with IRQs disabled, restarting KVM\u0026apos;s hrtimer\nover and over until the target expiration is advanced to \u0026quot;now\u0026quot; can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n ...\n RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n ...\n RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n PKRU: 55555554\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n apic_timer_fn+0x31/0x50 [kvm]\n __hrtimer_run_queues+0x100/0x280\n hrtimer_interrupt+0x100/0x210\n ? ttwu_do_wakeup+0x19/0x160\n smp_apic_timer_interrupt+0x6a/0x130\n apic_timer_interrupt+0xf/0x20\n \u0026lt;/IRQ\u0026gt;\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\u0026quot;KVM: VMX: Move preemption timer \u0026lt;=\u0026gt; hrtimer dance to common x86\u0026quot;), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way. Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---(CVE-2025-71104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not register unsupported perf events\n\nSynthetic events currently do not have a function to register perf events.\nThis leads to calling the tracepoint register functions with a NULL\nfunction pointer which triggers:\n\n ------------[ cut here ]------------\n WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:tracepoint_add_func+0x357/0x370\n Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc \u0026lt;0f\u0026gt; 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f\n RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246\n RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000\n RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8\n RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780\n R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a\n R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78\n FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register+0x5d/0x90\n synth_event_reg+0x3c/0x60\n perf_trace_event_init+0x204/0x340\n perf_trace_init+0x85/0xd0\n perf_tp_event_init+0x2e/0x50\n perf_try_init_event+0x6f/0x230\n ? perf_event_alloc+0x4bb/0xdc0\n perf_event_alloc+0x65a/0xdc0\n __se_sys_perf_event_open+0x290/0x9f0\n do_syscall_64+0x93/0x7b0\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? trace_hardirqs_off+0x53/0xc0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInstead, have the code return -ENODEV, which doesn\u0026apos;t warn and has perf\nerror out with:\n\n # perf record -e synthetic:futex_wait\nError:\nThe sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).\n\u0026quot;dmesg | grep -i perf\u0026quot; may provide additional information.\n\nIdeally perf should support synthetic events, but for now just fix the\nwarning. The support can come later.(CVE-2025-71125)",
"id": "OESA-2026-1275",
"modified": "2026-08-06T11:10:18Z",
"published": "2026-01-30T11:10:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1275"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50583"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54263"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37740"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37768"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38712"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68354"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71125"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49157",
"CVE-2022-50583",
"CVE-2022-50737",
"CVE-2023-53680",
"CVE-2023-53794",
"CVE-2023-54263",
"CVE-2025-37740",
"CVE-2025-37768",
"CVE-2025-38051",
"CVE-2025-38102",
"CVE-2025-38103",
"CVE-2025-38111",
"CVE-2025-38342",
"CVE-2025-38697",
"CVE-2025-38705",
"CVE-2025-38712",
"CVE-2025-38713",
"CVE-2025-38714",
"CVE-2025-39691",
"CVE-2025-39737",
"CVE-2025-39823",
"CVE-2025-39839",
"CVE-2025-39951",
"CVE-2025-39968",
"CVE-2025-40111",
"CVE-2025-40178",
"CVE-2025-40259",
"CVE-2025-68229",
"CVE-2025-68354",
"CVE-2025-68800",
"CVE-2025-68801",
"CVE-2025-71087",
"CVE-2025-71093",
"CVE-2025-71104",
"CVE-2025-71125"
]
}
OESA-2026-1303 (CVE-2024-57994)
Vulnerability from osv_openeuler – Published: 2026-02-06 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()
Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.
syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]
As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.
Rename helpers to better reflect they are safe against BH only.
- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
- skb_array_resize_multiple() to skb_array_resize_multiple_bh()
[1]
WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tun_ptr_free drivers/net/tun.c:617 [inline] __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline] ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline] tun_queue_resize drivers/net/tun.c:3694 [inline] tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550(CVE-2024-57994)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params
Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.(CVE-2024-58012)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential NULL pointer dereference in dev_uevent()
If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it.
Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing.(CVE-2025-37800)
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds clause 45 read/write access
When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.
Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38110)
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds read/write access
When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.
Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38111)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: clear phydev->devlink when the link is deleted
There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows.
[ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34
Therefore, phydev->devlink needs to be cleared when the device link is deleted.(CVE-2025-38149)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: prevent overflow in lookup table allocation
When calculating the lookup table size, ensure the following multiplication does not overflow:
- desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.
- NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.
- sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field.
Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this.
While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().(CVE-2025-38162)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: add NULL check in automount_fullpath
page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: fix race between nfsd registration and exports_proc
As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd.
Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd
for 5.4 kernel ARM64:
CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0
CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
PC is at : exports_net_open+0x50/0x68 [nfsd]
Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248
Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().
and same is happening on latest 6.14 kernel as well:
[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]---
It reproduced simply with below script: while [ 1 ] do /exportfs -r done &
while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done &
So exporting interfaces to user space shall be done at last and cleanup at first place.
With change there is no Kernel OOPs.(CVE-2025-38232)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential deadlock when reconnecting channels
Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening
====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W
cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200
but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30
other info that might help us debug this:
Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock);
*** DEADLOCK ***
3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200(CVE-2025-38244)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: eir: Fix possible crashes on eir_create_adv_data
eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.(CVE-2025-38303)
In the Linux kernel, the following vulnerability has been resolved:
software node: Correct a OOB check in software_node_get_reference_args()
software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property.
Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN
We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero.
It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.(CVE-2025-38393)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight
Reject migration of SEV{-ES} state if either the source or destination VM is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the section between incrementing created_vcpus and online_vcpus. The bulk of vCPU creation runs outside of kvm->lock to allow creating multiple vCPUs in parallel, and so sev_info.es_active can get toggled from false=>true in the destination VM after (or during) svm_vcpu_create(), resulting in an SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.
The issue manifests most visibly as a crash when trying to free a vCPU's NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.
BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:freepages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 </TASK> Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]---
Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated---(CVE-2025-38455)
In the Linux kernel, the following vulnerability has been resolved:
s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again
Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear.
Restore the fix and add a comment.(CVE-2025-38489)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Avoid stack buffer overflow from kernel cmdline
While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Prevent ALIGN() overflow
When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova.
Open code the ALIGN() using get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either.
Consolidate the two copies of this code under a single helper.
This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range.(CVE-2025-38688)
In the Linux kernel, the following vulnerability has been resolved:
jfs: upper bound check of tree index in dbAllocAG
When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.(CVE-2025-38697)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplus_fill_super() assumes that the attributes file is not yet created, which later results in hitting BUG_ON() when hfsplus_create_attributes_file() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc():
[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfxx64sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---(CVE-2025-38713)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
The hfsplus_bnode_read() method can trigger the issue:
[ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] <TASK> [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0 [ 174.854305][ T9784] print_report+0xd0/0x660 [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610 [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854337][ T9784] kasan_report+0xc6/0x100 [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360 [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380 [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10 [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0 [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310 [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0 [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0 [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10 [ 174.854427][ T9784] ? __pfxhfsplusdelete_attr+0x10/0x10 [ 174.854436][ T9784] ? asan_memset+0x23/0x50 [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320 [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10 [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0 [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0 [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10 [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10 [ 174.854525][ T9784] ? down_write+0x148/0x200 [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10 [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0 [ 174.854549][ T9784] do_unlinkat+0x490/0x670 [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10 [ 174.854565][ T9784] ? __might_fault+0xbc/0x130 [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550 [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110 [ 174.854592][ T9784] do_syscall_64+0xc9/0x480 [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] </TASK> [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasan_save_stack+0x20/0x40 [ 174.880082][ T9784] kasan_save_track+0x14/0x30 [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0 [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550 [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890 [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10 [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520 [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3 ---truncated---(CVE-2025-38714)
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix for slab out of bounds on mount to ksmbd
With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below):
BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827
CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 cifs
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix refcount leak causing resource not released
When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.(CVE-2025-39720)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - flush misc workqueue during device shutdown
Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded.
Since the driver uses a shared workqueue (qat_misc_wq) across all
devices and owned by intel_qat.ko, a deferred routine from the
device-specific driver may still be pending in the queue. If this
routine executes after the driver is unloaded, it can dereference freed
memory, resulting in a page fault and kernel crash like the following:
BUG: unable to handle page fault for address: ffa000002e50a01c
#PF: supervisor read access in kernel mode
RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
Call Trace:
pm_bh_handler+0x1d2/0x250 [intel_qat]
process_one_work+0x171/0x340
worker_thread+0x277/0x3a0
kthread+0xf0/0x120
ret_from_fork+0x2d/0x50
To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.
Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.(CVE-2025-39721)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()
The function needs to check the minimal filehandle length before it can access the embedded filehandle.(CVE-2025-39730)
In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()
A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.
watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]
The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.
The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects.
As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.(CVE-2025-39737)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Protect ->defer_qs_iw_pending from data race
On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.
In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.
The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat:
BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special
read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0
The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.
This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix the setting of capabilities when automounting a new filesystem
Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again.(CVE-2025-39798)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: use array_index_nospec with indices that come from guest
min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.(CVE-2025-39823)
In the Linux kernel, the following vulnerability has been resolved:
atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().
syzbot reported the splat below. [0]
When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.
The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.
The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.
struct atmtcp_control { struct atmtcp_hdr hdr; / must be first / ... atm_kptr_t vcc; / both directions / ... } __ATM_API_ALIGN;
typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;
The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().
atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:
- .ndo_start_xmit() (vcc->send() == atm_send_aal0())
- vcc_sendmsg()
The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.
Let's add a new ->pre_send() hook to validate messages from sendmsg().
[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 _syssendmsg+0x505/0x830 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in:(CVE-2025-39828)
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent NULL pointer dereference in UTF16 conversion
There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.
This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer.
Found by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix OOB read/write in network-coding decode
batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.
Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.(CVE-2025-39839)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix race condition validating r_parent before applying state
Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes.
[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated:
When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ](CVE-2025-39927)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path
During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()(CVE-2025-39929)
In the Linux kernel, the following vulnerability has been resolved:
um: virtio_uml: Fix use-after-free after put_device in probe
When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.(CVE-2025-39951)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix null-deref in agg_dequeue
To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c.
To avoid code duplication, the following changes are made:
-
Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function.
-
Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it.
-
Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Define a proc_layoutcommit for the FlexFiles layout type
Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.(CVE-2025-40087)
In the Linux kernel, the following vulnerability has been resolved:
cifs: parse_dfs_referrals: prevent oob on malformed input
Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS
- reply smaller than sizeof(struct get_dfs_referral_rsp)
- reply with number of referrals smaller than NumberOfReferrals in the header
Processing of such replies will cause oob.
Return -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix refcount leak for cifs_sb_tlink
Fix three refcount inconsistency issues related to cifs_sb_tlink.
Comments for cifs_sb_tlink state that cifs_put_tlink() needs to be
called after successful calls to cifs_sb_tlink(). Three calls fail to
update refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't leak disconnected dentries on umount
When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix Use-after-free in validation
Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.(CVE-2025-40111)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Clean up only new IRQ glue on request_irq() failure
The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added.
This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object.
Note: This error is observed when both fwctl and rds configs are enabled.
[1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI
RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: <TASK> ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a _syssendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b _sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---(CVE-2025-40250)
In the Linux kernel, the following vulnerability has been resolved:
net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()
The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array.
Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40252)
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Do not sleep in atomic context
sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.(CVE-2025-40259)
In the Linux kernel, the following vulnerability has been resolved:
nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()
nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur:
[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] </TASK>(CVE-2025-40261)
In the Linux kernel, the following vulnerability has been resolved:
be2net: pass wrb_params in case of OS2BMC
be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states.
The correct way would be to pass the wrb_params from be_xmit().(CVE-2025-40264)
In the Linux kernel, the following vulnerability has been resolved:
cifs: client: fix memory leak in smb3_fs_context_parse_param
The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation.
To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing.
syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444
BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: free copynotify stateid in nfs4_free_ol_stateid()
Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period.
However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred
WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]
This patch, instead, frees the associated copynotify stateid here.
If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later.
[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: cancel mesh send timer when hdev removed
mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone.
Cancel the timer when MGMT removes the hdev, like other MGMT timers.
Should fix the BUG: sporadically seen by BlueZ test bot (in "Mesh - Send cancel - 1" test).
Log:
BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------(CVE-2025-40284)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches.
Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)
In the Linux kernel, the following vulnerability has been resolved:
accel/habanalabs: support mapping cb with vmalloc-backed coherent memory
When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction.
Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.(CVE-2025-40311)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget
In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free.
Fix: By separating the usb_del_gadget_udc() operation into distinct "del" and "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget().
A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").(CVE-2025-40314)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Sync pending IRQ work before freeing ring buffer
Fix a race where irq_work can be queued in bpf_ringbuf_commit()
but the ring buffer is freed before the work executes.
In the syzbot reproducer, a BPF program attached to sched_switch
triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer
is freed before this work executes, the irq_work thread may accesses
freed memory.
Calling irq_work_sync(&rb->work) ensures that all pending irq_work
complete before freeing the buffer.(CVE-2025-40319)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential cfid UAF in smb2_query_info_compound
When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free.
Reinitialize cfid to NULL under the replay label.
Example trace (trimmed):
refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: <TASK> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80(CVE-2025-40320)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: bitblit: bound-check glyph index in bit_putcs*
bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address.
This fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix crash in nfsd4_read_release()
When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.(CVE-2025-40324)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_close_cached_fid()
find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free.
Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.(CVE-2025-40328)
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: sddr55: Reject out-of-bound new_pba
Discovered by Atuin - Automated Vulnerability Discovery Engine.
new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory.
Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ
XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run.
Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it.
To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.(CVE-2025-40350)
In the Linux kernel, the following vulnerability has been resolved:
drm/sysfb: Do not dereference NULL pointer in plane reset
The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL.
v2: - fix typo in commit description (Javier)(CVE-2025-40360)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix field-spanning memcpy warning in AH output
Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields.
memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439
The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.(CVE-2025-40363)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix possible deadlock while configuring policy
Following deadlock can be triggered easily by lockdep:
WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted
check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180
but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30
-> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
other info that might help us debug this:
Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock);
Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context.
The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.(CVE-2025-68178)
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Disable AFBC support on Mediatek DRM driver
Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier.
However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0.
Kernel trace reports vblank timeouts constantly, and the render is garbled:
[CRTC:62:crtc-0] vblank wait timed out
WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
[...]
Hardware name: MediaTek Genio-700 EVK (DT)
Workqueue: events_unbound commit_work
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
sp : ffff80008337bca0
x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000
x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000
x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80
x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a
x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000
x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b
x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70
x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70
x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480
Call trace:
drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)
drm_atomic_helper_commit_tail_rpm+0x64/0x80
commit_tail+0xa4/0x1a4
commit_work+0x14/0x20
process_one_work+0x150/0x290
worker_thread+0x2d0/0x3ec
kthread+0x12c/0x210
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.(CVE-2025-68184)
In the Linux kernel, the following vulnerability has been resolved:
nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack.
Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.(CVE-2025-68185)
In the Linux kernel, the following vulnerability has been resolved:
udp_tunnel: use netdev_warn() instead of netdev_WARN()
netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug.
udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug.
Replace netdev_WARN() with netdev_warn() accordingly.(CVE-2025-68191)
In the Linux kernel, the following vulnerability has been resolved:
nvme-multipath: fix lockdep WARN due to partition scan work
Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion.
To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.(CVE-2025-68218)
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix memory leak in smb3_fs_context_parse_param error path
Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues.
This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed.
The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak.
This issue was not addressed by commit e8c73eb7db0a ("cifs: client: fix memory leak in smb3_fs_context_parse_param"), which only fixed leaks from repeated fsconfig() calls but not this error path.
Patch updated with minor change suggested by kernel test robot(CVE-2025-68219)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.
Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...(CVE-2025-68229)
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: restore write access before closing files opened by open_exec()
bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed.
However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail.
Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.(CVE-2025-68239)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random.
The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked.
CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]
This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device:
unregister_netdevice: waiting for sitX to become free. Usage count = N
Ido Schimmel provided the simple test validation method [1].
The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed.
[1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1(CVE-2025-68241)
In the Linux kernel, the following vulnerability has been resolved:
net: netpoll: fix incorrect refcount handling causing incorrect cleanup
commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks.
Scenario causing lack of proper cleanup:
1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.
2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.
3) When the first netpolls goes to clean up:
- The first cleanup succeeds and clears np->dev->npinfo, ignoring
refcnt.
- It basically calls RCU_INIT_POINTER(np->dev->npinfo, NULL);
- Set dev->npinfo = NULL, without proper cleanup
- No ->ndo_netpoll_cleanup() is either called
4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.
Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.(CVE-2025-68245)
In the Linux kernel, the following vulnerability has been resolved:
erofs: avoid infinite loops due to corrupted subpage compact indexes
Robert reported an infinite loop observed by two crafted images.
The root cause is that clusterofs can be larger than lclustersize
for !NONHEAD lclusters in corrupted subpage compact indexes, e.g.:
blocksize = lclustersize = 512 lcn = 6 clusterofs = 515
Move the corresponding check for full compress indexes to
z_erofs_load_lcluster_from_disk() to also cover subpage compact
compress indexes.
It also fixes the position of m->type >= Z_EROFS_LCLUSTER_TYPE_MAX
check, since it should be placed right after
z_erofs_load_{compact,full}_lcluster().(CVE-2025-68251)
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase.
Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.(CVE-2025-68288)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix memory leak in cifs_construct_tcon()
When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon().
This fixes the following memory leak reported by kmemleak:
mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-68295)
In the Linux kernel, the following vulnerability has been resolved:
drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup
Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs.
VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array.
Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly.
Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all().
Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.(CVE-2025-68296)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sock: Prevent race in socket write iter and sock bind
There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1].
Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1].
[1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195
Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195
Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)
In the Linux kernel, the following vulnerability has been resolved:
s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump
Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do.
During error recovery testing a pair of tasks was reported to be hung:
mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]
No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too:
- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()
- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.
A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/<BDF> reporter fw_fatal
while PCI error recovery is executed on the same <BDF> physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw <BDF>
Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with "kernel answers: Permission denied" - and we get a kernel log message of:
mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5
because the config read of VSC_SEMAPHORE is rejected by the underlying hardware.
Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.(CVE-2025-68310)
In the Linux kernel, the following vulnerability has been resolved:
usbnet: Prevents free active kevent
The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here.
- Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed.
The solution to this problem is to cancel the kevent before executing free_netdev().(CVE-2025-68312)
In the Linux kernel, the following vulnerability has been resolved:
nbd: defer config unlock in nbd_genl_connect
There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK:
nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf
------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790
The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect():
mutex_unlock(&nbd->config_lock);
if (!ret) {
set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);
- printk("before sleep\n");
- mdelay(5 * 1000);
- printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }(CVE-2025-68366)
In the Linux kernel, the following vulnerability has been resolved:
macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse
The following warning appears when running syzkaller, and this issue also exists in the mainline code.
------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2
The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler.
CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = valp // old_val=0 old_val = valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()
Fix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)
In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Fix device resources accessed after device removal
Correct possible race conditions during device removal.
Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.
This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources.
-
Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.
-
Cancel any pending TMF work that has not started in sdev_destroy().
-
Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)
In the Linux kernel, the following vulnerability has been resolved:
nbd: defer config put in recv_work
There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF
Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF
Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the waiter") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared.
However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup.
Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave.
In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock):
path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work
path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0
Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")(CVE-2025-68372)
In the Linux kernel, the following vulnerability has been resolved:
md: fix rcu protection in md_wakeup_thread
We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.(CVE-2025-68374)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix null deref on srq->rq.queue after resize failure
A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask.
Call Trace: <TASK> rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfxrawspin_lock_irqsave+0x10/0x10 ? pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-68379)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags
When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.(CVE-2025-68764)
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: do not generate ACCESS/MODIFY events on child for special files
inotify/fanotify do not allow users with no read access to a file to subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the same user to subscribe for watching events on children when the user has access to the parent directory (e.g. /dev).
Users with no read access to a file but with read access to its parent directory can still stat the file and see if it was accessed/modified via atime/mtime change.
The same is not true for special files (e.g. /dev/null). Users will not generally observe atime/mtime changes when other users read/write to special files, only when someone sets atime/mtime via utimensat().
Align fsnotify events with this stat behavior and do not generate ACCESS/MODIFY events to parent watchers on read/write of special files. The events are still generated to parent watchers on utimensat(). This closes some side-channels that could be possibly used for information exfiltration [1].
[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)
In the Linux kernel, the following vulnerability has been resolved:
fuse: missing copy_finish in fuse-over-io-uring argument copies
Fix a possible reference count leak of payload pages during fuse argument copies.
Joanne: simplified error cleanup
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd: Check event before enable to avoid GPF
On AMD machines cpuc->events[idx] can become NULL in a subtle race condition with NMI->throttle->x86_pmu_stop().
Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF. This appears to be an AMD only issue.
Syzkaller reported a GPF in amd_pmu_enable_all.
INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143 msecs Oops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7] CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430) RSP: 0018:ffff888118009d60 EFLAGS: 00010012 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601 FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0 Call Trace: <IRQ> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2)) x86_pmu_enable (arch/x86/events/core.c:1360) event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346) __perf_remove_from_context (kernel/events/core.c:2435) event_function (kernel/events/core.c:259) remote_function (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1)) __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540) __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272) sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47)) </IRQ>(CVE-2025-68798)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats
Cited commit added a dedicated mutex (instead of RTNL) to protect the multicast route list, so that it will not change while the driver periodically traverses it in order to update the kernel about multicast route stats that were queried from the device.
One instance of list entry deletion (during route replace) was missed and it can result in a use-after-free [1].
Fix by acquiring the mutex before deleting the entry from the list and releasing it afterwards.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043
CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum] Call Trace: <TASK> dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30
Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30(CVE-2025-68800)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix neighbour use-after-free
We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.
Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.
Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929
CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 _syssendmsg+0x5b2/0x7d0 _sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [...]
Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20(CVE-2025-68801)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix io-uring list corruption for terminated non-committed requests
When a request is terminated before it has been committed, the request is not removed from the queue's list. This leaves a dangling list entry that leads to list corruption and use-after-free issues.
Remove the request from the queue's list for terminated non-committed requests.(CVE-2025-68805)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix readahead reclaim deadlock
Commit e26ee4efbc79 ("fuse: allocate ff->release_args only if release is needed") skips allocating ff->release_args if the server does not implement open. However in doing so, fuse_prepare_release() now skips grabbing the reference on the inode, which makes it possible for an inode to be evicted from the dcache while there are inflight readahead requests. This causes a deadlock if the server triggers reclaim while servicing the readahead request and reclaim attempts to evict the inode of the file being read ahead. Since the folio is locked during readahead, when reclaim evicts the fuse inode and fuse_evict_inode() attempts to remove all folios associated with the inode from the page cache (truncate_inode_pages_range()), reclaim will block forever waiting for the lock since readahead cannot relinquish the lock because it is itself blocked in reclaim:
>>> stack_trace(1504735) folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate.c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache.c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c:221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195:3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/x86/mm/fault.c:1481:3) exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27
Fix this deadlock by allocating ff->release_args and grabbing the reference on the inode when preparing the file for release even if the server does not implement open. The inode reference will be dropped when the last reference on the fuse file is dropped (see fuse_file_put() -> fuse_release_end()).(CVE-2025-68821)
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix off-by-one issues in iavf_config_rss_reg()
There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX which is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4
where rss_{key,lut}_size / 4 is the number of dwords, so the last
valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <=
accesses one element past the end.
Fix the issues by using < instead of <=, ensuring we do not exceed
the bounds.
[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)
In the Linux kernel, the following vulnerability has been resolved:
e1000: fix OOB in e1000_tbi_should_accept()
In e1000_tbi_should_accept() we read the last byte of the frame via 'data[length - 1]' to evaluate the TBI workaround. If the descriptor- reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq):
================================================================== BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790 Read of size 1 at addr ffff888014114e54 by task sshd/363
CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 </IRQ> <TASK> __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f511b476b10 Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 </TASK> Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30 The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800] The buggy address belongs to the physical page: page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110 head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected ==================================================================
This happens because the TBI check unconditionally dereferences the last byte without validating the reported length first:
u8 last_byte = *(data + length - 1);
Fix by rejecting the frame early if the length is zero, or if it exceeds adapter->rx_buffer_len. This preserves the TBI workaround semantics for valid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Handle incorrect num_connectors capability
The UCSI spec states that the num_connectors field is 7 bits, and the 8th bit is reserved and should be set to zero. Some buggy FW has been known to set this bit, and it can lead to a system not booting. Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly.
Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported.(CVE-2025-71108)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - zero initialize memory allocated via sock_kmalloc
Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future.
The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures.
A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit:
67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")
Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:
https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209
The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.(CVE-2025-71113)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/kexec: Enable SMT before waking offline CPUs
If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed:
kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc [snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec
This occurs as add_cpu() fails due to cpu_bootable() returning false for CPUs that fail the cpu_smt_thread_allowed() check or non primary threads if SMT is disabled.
Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.(CVE-2025-71119)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Do not register unsupported perf events
Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:
------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:
# perf record -e synthetic:futex_wait Error: The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.
Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.(CVE-2025-71125)
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory and information leak in smb3_reconfigure()
In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak.
Fix this by calling kfree_sensitive() on both password buffers before returning in this error case.(CVE-2025-71151)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-source-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"perf-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"python3-perf-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-138.0.0.119.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-source-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"perf-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"python3-perf-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-138.0.0.119.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-138.0.0.119.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()\n\nJakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()\nto increase test coverage.\n\nsyzbot found a splat caused by hard irq blocking in\nptr_ring_resize_multiple() [1]\n\nAs current users of ptr_ring_resize_multiple() do not require\nhard irqs being masked, replace it to only block BH.\n\nRename helpers to better reflect they are safe against BH only.\n\n- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()\n- skb_array_resize_multiple() to skb_array_resize_multiple_bh()\n\n[1]\n\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nModules linked in:\nCPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]\nRIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nCode: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 \u0026lt;0f\u0026gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85\nRSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083\nRAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000\nRDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843\nRBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d\nR10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040\nR13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff\nFS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tun_ptr_free drivers/net/tun.c:617 [inline]\n __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline]\n ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline]\n tun_queue_resize drivers/net/tun.c:3694 [inline]\n tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714\n notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93\n call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]\n call_netdevice_notifiers net/core/dev.c:2046 [inline]\n dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024\n do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923\n rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201\n rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550(CVE-2024-57994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params\n\nEach cpu DAI should associate with a widget. However, the topology might\nnot create the right number of DAI widgets for aggregated amps. And it\nwill cause NULL pointer deference.\nCheck that the DAI widget associated with the CPU DAI is valid to prevent\nNULL pointer deference due to missing DAI widgets in topologies with\naggregated amps.(CVE-2024-58012)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential NULL pointer dereference in dev_uevent()\n\nIf userspace reads \u0026quot;uevent\u0026quot; device attribute at the same time as another\nthreads unbinds the device from its driver, change to dev-\u0026gt;driver from a\nvalid pointer to NULL may result in crash. Fix this by using READ_ONCE()\nwhen fetching the pointer, and take bus\u0026apos; drivers klist lock to make sure\ndriver instance will not disappear while we access it.\n\nUse WRITE_ONCE() when setting the driver pointer to ensure there is no\ntearing.(CVE-2025-37800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds clause 45 read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via C45 (clause 45) mdiobus,\nthere is no verification of parameters passed to the ioctl and\nit accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before C45 read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via mdiobus, there is no verification of\nparameters passed to the ioctl and it accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: clear phydev-\u0026gt;devlink when the link is deleted\n\nThere is a potential crash issue when disabling and re-enabling the\nnetwork port. When disabling the network port, phy_detach() calls\ndevice_link_del() to remove the device link, but it does not clear\nphydev-\u0026gt;devlink, so phydev-\u0026gt;devlink is not a NULL pointer. Then the\nnetwork port is re-enabled, but if phy_attach_direct() fails before\ncalling device_link_add(), the code jumps to the \u0026quot;error\u0026quot; label and\ncalls phy_detach(). Since phydev-\u0026gt;devlink retains the old value from\nthe previous attach/detach cycle, device_link_del() uses the old value,\nwhich accesses a NULL pointer and causes a crash. The simplified crash\nlog is as follows.\n\n[ 24.702421] Call trace:\n[ 24.704856] device_link_put_kref+0x20/0x120\n[ 24.709124] device_link_del+0x30/0x48\n[ 24.712864] phy_detach+0x24/0x168\n[ 24.716261] phy_attach_direct+0x168/0x3a4\n[ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c\n[ 24.725140] phylink_of_phy_connect+0x1c/0x34\n\nTherefore, phydev-\u0026gt;devlink needs to be cleared when the device link is\ndeleted.(CVE-2025-38149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: prevent overflow in lookup table allocation\n\nWhen calculating the lookup table size, ensure the following\nmultiplication does not overflow:\n\n- desc-\u0026gt;field_len[] maximum value is U8_MAX multiplied by\n NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.\n- NFT_PIPAPO_BUCKETS(f-\u0026gt;bb) is 2^8, worst case.\n- sizeof(unsigned long), from sizeof(*f-\u0026gt;lt), lt in\n struct nft_pipapo_field.\n\nThen, use check_mul_overflow() to multiply by bucket size and then use\ncheck_add_overflow() to the alignment for avx2 (if needed). Finally, add\nlt_size_check_overflow() helper and use it to consolidate this.\n\nWhile at it, replace leftover allocation using the GFP_KERNEL to\nGFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().(CVE-2025-38162)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: add NULL check in automount_fullpath\n\npage is checked for null in __build_path_from_dentry_optional_prefix\nwhen tcon-\u0026gt;origin_fullpath is not set. However, the check is missing when\nit is set.\nAdd a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix race between nfsd registration and exports_proc\n\nAs of now nfsd calls create_proc_exports_entry() at start of init_nfsd\nand cleanup by remove_proc_entry() at last of exit_nfsd.\n\nWhich causes kernel OOPs if there is race between below 2 operations:\n(i) exportfs -r\n(ii) mount -t nfsd none /proc/fs/nfsd\n\nfor 5.4 kernel ARM64:\n\nCPU 1:\nel1_irq+0xbc/0x180\narch_counter_get_cntvct+0x14/0x18\nrunning_clock+0xc/0x18\npreempt_count_add+0x88/0x110\nprep_new_page+0xb0/0x220\nget_page_from_freelist+0x2d8/0x1778\n__alloc_pages_nodemask+0x15c/0xef0\n__vmalloc_node_range+0x28c/0x478\n__vmalloc_node_flags_caller+0x8c/0xb0\nkvmalloc_node+0x88/0xe0\nnfsd_init_net+0x6c/0x108 [nfsd]\nops_init+0x44/0x170\nregister_pernet_operations+0x114/0x270\nregister_pernet_subsys+0x34/0x50\ninit_nfsd+0xa8/0x718 [nfsd]\ndo_one_initcall+0x54/0x2e0\n\nCPU 2 :\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000010\n\nPC is at : exports_net_open+0x50/0x68 [nfsd]\n\nCall trace:\nexports_net_open+0x50/0x68 [nfsd]\nexports_proc_open+0x2c/0x38 [nfsd]\nproc_reg_open+0xb8/0x198\ndo_dentry_open+0x1c4/0x418\nvfs_open+0x38/0x48\npath_openat+0x28c/0xf18\ndo_filp_open+0x70/0xe8\ndo_sys_open+0x154/0x248\n\nSometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().\n\nand same is happening on latest 6.14 kernel as well:\n\n[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty\n...\n[ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48\n...\n[ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4\n...\n[ 285.469695] Call trace:\n[ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)\n[ 285.470488] seq_read+0xe0/0x11c\n[ 285.470675] proc_reg_read+0x9c/0xf0\n[ 285.470874] vfs_read+0xc4/0x2fc\n[ 285.471057] ksys_read+0x6c/0xf4\n[ 285.471231] __arm64_sys_read+0x1c/0x28\n[ 285.471428] invoke_syscall+0x44/0x100\n[ 285.471633] el0_svc_common.constprop.0+0x40/0xe0\n[ 285.471870] do_el0_svc_compat+0x1c/0x34\n[ 285.472073] el0_svc_compat+0x2c/0x80\n[ 285.472265] el0t_32_sync_handler+0x90/0x140\n[ 285.472473] el0t_32_sync+0x19c/0x1a0\n[ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)\n[ 285.473422] ---[ end trace 0000000000000000 ]---\n\nIt reproduced simply with below script:\nwhile [ 1 ]\ndo\n/exportfs -r\ndone \u0026amp;\n\nwhile [ 1 ]\ndo\ninsmod /nfsd.ko\nmount -t nfsd none /proc/fs/nfsd\numount /proc/fs/nfsd\nrmmod nfsd\ndone \u0026amp;\n\nSo exporting interfaces to user space shall be done at last and\ncleanup at first place.\n\nWith change there is no Kernel OOPs.(CVE-2025-38232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential deadlock when reconnecting channels\n\nFix cifs_signal_cifsd_for_reconnect() to take the correct lock order\nand prevent the following deadlock from happening\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.16.0-rc3-build2+ #1301 Tainted: G S W\n------------------------------------------------------\ncifsd/6055 is trying to acquire lock:\nffff88810ad56038 (\u0026amp;tcp_ses-\u0026gt;srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200\n\nbut task is already holding lock:\nffff888119c64330 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}:\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_setup_session+0x81/0x4b0\n cifs_get_smb_ses+0x771/0x900\n cifs_mount_get_session+0x7e/0x170\n cifs_mount+0x92/0x2d0\n cifs_smb3_do_mount+0x161/0x460\n smb3_get_tree+0x55/0x90\n vfs_get_tree+0x46/0x180\n do_new_mount+0x1b0/0x2e0\n path_mount+0x6ee/0x740\n do_mount+0x98/0xe0\n __do_sys_mount+0x148/0x180\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #1 (\u0026amp;ret_buf-\u0026gt;ses_lock){+.+.}-{3:3}:\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_match_super+0x101/0x320\n sget+0xab/0x270\n cifs_smb3_do_mount+0x1e0/0x460\n smb3_get_tree+0x55/0x90\n vfs_get_tree+0x46/0x180\n do_new_mount+0x1b0/0x2e0\n path_mount+0x6ee/0x740\n do_mount+0x98/0xe0\n __do_sys_mount+0x148/0x180\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #0 (\u0026amp;tcp_ses-\u0026gt;srv_lock){+.+.}-{3:3}:\n check_noncircular+0x95/0xc0\n check_prev_add+0x115/0x2f0\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_signal_cifsd_for_reconnect+0x134/0x200\n __cifs_reconnect+0x8f/0x500\n cifs_handle_standard+0x112/0x280\n cifs_demultiplex_thread+0x64d/0xbc0\n kthread+0x2f7/0x310\n ret_from_fork+0x2a/0x230\n ret_from_fork_asm+0x1a/0x30\n\nother info that might help us debug this:\n\nChain exists of:\n \u0026amp;tcp_ses-\u0026gt;srv_lock --\u0026gt; \u0026amp;ret_buf-\u0026gt;ses_lock --\u0026gt; \u0026amp;ret_buf-\u0026gt;chan_lock\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;ret_buf-\u0026gt;chan_lock);\n lock(\u0026amp;ret_buf-\u0026gt;ses_lock);\n lock(\u0026amp;ret_buf-\u0026gt;chan_lock);\n lock(\u0026amp;tcp_ses-\u0026gt;srv_lock);\n\n *** DEADLOCK ***\n\n3 locks held by cifsd/6055:\n #0: ffffffff857de398 (\u0026amp;cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200\n #1: ffff888119c64060 (\u0026amp;ret_buf-\u0026gt;ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200\n #2: ffff888119c64330 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200(CVE-2025-38244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix possible crashes on eir_create_adv_data\n\neir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER\nwithout checking if that would fit.(CVE-2025-38303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoftware node: Correct a OOB check in software_node_get_reference_args()\n\nsoftware_node_get_reference_args() wants to get @index-th element, so\nthe property value requires at least \u0026apos;(index + 1) * sizeof(*ref)\u0026apos; bytes\nbut that can not be guaranteed by current OOB check, and may cause OOB\nfor malformed property.\n\nFix by using as OOB check \u0026apos;((index + 1) * sizeof(*ref) \u0026gt; prop-\u0026gt;length)\u0026apos;.(CVE-2025-38342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN\n\nWe found a few different systems hung up in writeback waiting on the same\npage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in\npnfs_update_layout(), however the pnfs_layout_hdr\u0026apos;s plh_outstanding count\nwas zero.\n\nIt seems most likely that this is another race between the waiter and waker\nsimilar to commit ed0172af5d6f (\u0026quot;SUNRPC: Fix a race to wake a sync task\u0026quot;).\nFix it up by applying the advised barrier.(CVE-2025-38393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight\n\nReject migration of SEV{-ES} state if either the source or destination VM\nis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the\nsection between incrementing created_vcpus and online_vcpus. The bulk of\nvCPU creation runs _outside_ of kvm-\u0026gt;lock to allow creating multiple vCPUs\nin parallel, and so sev_info.es_active can get toggled from false=\u0026gt;true in\nthe destination VM after (or during) svm_vcpu_create(), resulting in an\nSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.\n\nThe issue manifests most visibly as a crash when trying to free a vCPU\u0026apos;s\nNULL VMSA page in an SEV-ES VM, but any number of things can go wrong.\n\n BUG: unable to handle page fault for address: ffffebde00000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP KASAN NOPTI\n CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024\n RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]\n RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]\n RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]\n RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]\n RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067\n Code: \u0026lt;49\u0026gt; f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0\n RSP: 0018:ffff8984551978d0 EFLAGS: 00010246\n RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98\n RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000\n RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000\n R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000\n R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000\n FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0\n DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169\n svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515\n kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396\n kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]\n kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490\n kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895\n kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310\n kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369\n __fput+0x3e4/0x9e0 fs/file_table.c:465\n task_work_run+0x1a9/0x220 kernel/task_work.c:227\n exit_task_work include/linux/task_work.h:40 [inline]\n do_exit+0x7f0/0x25b0 kernel/exit.c:953\n do_group_exit+0x203/0x2d0 kernel/exit.c:1102\n get_signal+0x1357/0x1480 kernel/signal.c:3034\n arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218\n do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f87a898e969\n \u0026lt;/TASK\u0026gt;\n Modules linked in: gq(O)\n gsmi: Log Shutdown Reason 0x03\n CR2: ffffebde00000000\n ---[ end trace 0000000000000000 ]---\n\nDeliberately don\u0026apos;t check for a NULL VMSA when freeing the vCPU, as crashing\nthe host is likely desirable due to the VMSA being consumed by hardware.\nE.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a\nbogus VMSA page. Accessing P\n---truncated---(CVE-2025-38455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again\n\nCommit 7ded842b356d (\u0026quot;s390/bpf: Fix bpf_plt pointer arithmetic\u0026quot;) has\naccidentally removed the critical piece of commit c730fce7c70c\n(\u0026quot;s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL\u0026quot;), causing\nintermittent kernel panics in e.g. perf\u0026apos;s on_switch() prog to reappear.\n\nRestore the fix and add a comment.(CVE-2025-38489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Avoid stack buffer overflow from kernel cmdline\n\nWhile the kernel command line is considered trusted in most environments,\navoid writing 1 byte past the end of \u0026quot;acpiid\u0026quot; if the \u0026quot;str\u0026quot; argument is\nmaximum length.(CVE-2025-38676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Prevent ALIGN() overflow\n\nWhen allocating IOVA the candidate range gets aligned to the target\nalignment. If the range is close to ULONG_MAX then the ALIGN() can\nwrap resulting in a corrupted iova.\n\nOpen code the ALIGN() using get_add_overflow() to prevent this.\nThis simplifies the checks as we don\u0026apos;t need to check for length earlier\neither.\n\nConsolidate the two copies of this code under a single helper.\n\nThis bug would allow userspace to create a mapping that overlaps with some\nother mapping or a reserved range.(CVE-2025-38688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: upper bound check of tree index in dbAllocAG\n\nWhen computing the tree index in dbAllocAG, we never check if we are\nout of bounds realative to the size of the stree.\nThis could happen in a scenario where the filesystem metadata are\ncorrupted.(CVE-2025-38697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: don\u0026apos;t use BUG_ON() in hfsplus_create_attributes_file()\n\nWhen the volume header contains erroneous values that do not reflect\nthe actual state of the filesystem, hfsplus_fill_super() assumes that\nthe attributes file is not yet created, which later results in hitting\nBUG_ON() when hfsplus_create_attributes_file() is called. Replace this\nBUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nThe hfsplus_readdir() method is capable to crash by calling\nhfsplus_uni2asc():\n\n[ 667.121659][ T9805] ==================================================================\n[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10\n[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805\n[ 667.124578][ T9805]\n[ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)\n[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 667.124890][ T9805] Call Trace:\n[ 667.124893][ T9805] \u0026lt;TASK\u0026gt;\n[ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0\n[ 667.124911][ T9805] print_report+0xd0/0x660\n[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610\n[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180\n[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124942][ T9805] kasan_report+0xc6/0x100\n[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10\n[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360\n[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0\n[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10\n[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0\n[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0\n[ 667.125022][ T9805] ? lock_acquire+0x30/0x80\n[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0\n[ 667.125044][ T9805] ? putname+0x154/0x1a0\n[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10\n[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0\n[ 667.125069][ T9805] iterate_dir+0x296/0xb20\n[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10\n[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200\n[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10\n[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0\n[ 667.125143][ T9805] do_syscall_64+0xc9/0x480\n[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9\n[ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48\n[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9\n[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9\n[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004\n[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110\n[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260\n[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 667.125207][ T9805] \u0026lt;/TASK\u0026gt;\n[ 667.125210][ T9805]\n[ 667.145632][ T9805] Allocated by task 9805:\n[ 667.145991][ T9805] kasan_save_stack+0x20/0x40\n[ 667.146352][ T9805] kasan_save_track+0x14/0x30\n[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0\n[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550\n[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0\n[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0\n[ 667.148174][ T9805] iterate_dir+0x296/0xb20\n[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.148937][ T9805] do_syscall_64+0xc9/0x480\n[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.149809][ T9805]\n[ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000\n[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048\n[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of\n[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)\n[ 667.1\n---truncated---(CVE-2025-38713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()\n\nThe hfsplus_bnode_read() method can trigger the issue:\n\n[ 174.852007][ T9784] ==================================================================\n[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360\n[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784\n[ 174.854059][ T9784]\n[ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)\n[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 174.854286][ T9784] Call Trace:\n[ 174.854289][ T9784] \u0026lt;TASK\u0026gt;\n[ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0\n[ 174.854305][ T9784] print_report+0xd0/0x660\n[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610\n[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180\n[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854337][ T9784] kasan_report+0xc6/0x100\n[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360\n[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380\n[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10\n[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0\n[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310\n[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0\n[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0\n[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10\n[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10\n[ 174.854436][ T9784] ? __asan_memset+0x23/0x50\n[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320\n[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10\n[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0\n[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0\n[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10\n[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0\n[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10\n[ 174.854525][ T9784] ? down_write+0x148/0x200\n[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10\n[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0\n[ 174.854549][ T9784] do_unlinkat+0x490/0x670\n[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10\n[ 174.854565][ T9784] ? __might_fault+0xbc/0x130\n[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550\n[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110\n[ 174.854592][ T9784] do_syscall_64+0xc9/0x480\n[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167\n[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08\n[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057\n[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167\n[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50\n[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40\n[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0\n[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 174.854658][ T9784] \u0026lt;/TASK\u0026gt;\n[ 174.854661][ T9784]\n[ 174.879281][ T9784] Allocated by task 9784:\n[ 174.879664][ T9784] kasan_save_stack+0x20/0x40\n[ 174.880082][ T9784] kasan_save_track+0x14/0x30\n[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0\n[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550\n[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890\n[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10\n[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520\n[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3\n---truncated---(CVE-2025-38714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix for slab out of bounds on mount to ksmbd\n\nWith KASAN enabled, it is possible to get a slab out of bounds\nduring mount to ksmbd due to missing check in parse_server_interfaces()\n(see below):\n\n BUG: KASAN: slab-out-of-bounds in\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n Read of size 4 at addr ffff8881433dba98 by task mount/9827\n\n CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G\n OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary)\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,\n BIOS 2.13.1 06/14/2019\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x9f/0xf0\n print_report+0xd1/0x670\n __virt_addr_valid+0x22c/0x430\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? kasan_complete_mode_report_info+0x2a/0x1f0\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n kasan_report+0xd6/0x110\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n __asan_report_load_n_noabort+0x13/0x20\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]\n ? trace_hardirqs_on+0x51/0x60\n SMB3_request_interfaces+0x1ad/0x3f0 [cifs]\n ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]\n ? SMB2_tcon+0x23c/0x15d0 [cifs]\n smb3_qfs_tcon+0x173/0x2b0 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n cifs_mount_get_tcon+0x369/0xb90 [cifs]\n ? dfs_cache_find+0xe7/0x150 [cifs]\n dfs_mount_share+0x985/0x2970 [cifs]\n ? check_path.constprop.0+0x28/0x50\n ? save_trace+0x54/0x370\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? __lock_acquire+0xb82/0x2ba0\n ? __kasan_check_write+0x18/0x20\n cifs_mount+0xbc/0x9e0 [cifs]\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]\n cifs_smb3_do_mount+0x263/0x1990 [cifs](CVE-2025-38728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix refcount leak causing resource not released\n\nWhen ksmbd_conn_releasing(opinfo-\u0026gt;conn) returns true,the refcount was not\ndecremented properly, causing a refcount leak that prevents the count from\nreaching zero and the memory from being released.(CVE-2025-39720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - flush misc workqueue during device shutdown\n\nRepeated loading and unloading of a device specific QAT driver, for\nexample qat_4xxx, in a tight loop can lead to a crash due to a\nuse-after-free scenario. This occurs when a power management (PM)\ninterrupt triggers just before the device-specific driver (e.g.,\nqat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains\nloaded.\n\nSince the driver uses a shared workqueue (`qat_misc_wq`) across all\ndevices and owned by intel_qat.ko, a deferred routine from the\ndevice-specific driver may still be pending in the queue. If this\nroutine executes after the driver is unloaded, it can dereference freed\nmemory, resulting in a page fault and kernel crash like the following:\n\n BUG: unable to handle page fault for address: ffa000002e50a01c\n #PF: supervisor read access in kernel mode\n RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]\n Call Trace:\n pm_bh_handler+0x1d2/0x250 [intel_qat]\n process_one_work+0x171/0x340\n worker_thread+0x277/0x3a0\n kthread+0xf0/0x120\n ret_from_fork+0x2d/0x50\n\nTo prevent this, flush the misc workqueue during device shutdown to\nensure that all pending work items are completed before the driver is\nunloaded.\n\nNote: This approach may slightly increase shutdown latency if the\nworkqueue contains jobs from other devices, but it ensures correctness\nand stability.(CVE-2025-39721)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix filehandle bounds checking in nfs_fh_to_dentry()\n\nThe function needs to check the minimal filehandle length before it can\naccess the embedded filehandle.(CVE-2025-39730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel. Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects. The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue. In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn\u0026apos;t really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen. So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.(CVE-2025-39737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect -\u0026gt;defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won\u0026apos;t happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure\u0026apos;s -\u0026gt;defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special(). This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last enabled at (200272): [\u0026lt;ffffffffb0f56121\u0026gt;] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [\u0026lt;ffffffffb25c7859\u0026gt;] __schedule+0x129/0xd70\nsoftirqs last enabled at (0): [\u0026lt;ffffffffb0ee093f\u0026gt;] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special(). In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe -\u0026gt;defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the -\u0026gt;defer_qs_iw_pending\nfield. This suffices because this handler is not a fast path.(CVE-2025-39749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix the setting of capabilities when automounting a new filesystem\n\nCapabilities cannot be inherited when we cross into a new filesystem.\nThey need to be reset to the minimal defaults, and then probed for\nagain.(CVE-2025-39798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: use array_index_nospec with indices that come from guest\n\nmin and dest_id are guest-controlled indices. Using array_index_nospec()\nafter the bounds checks clamps these values to mitigate speculative execution\nside-channels.(CVE-2025-39823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().\n\nsyzbot reported the splat below. [0]\n\nWhen atmtcp_v_open() or atmtcp_v_close() is called via connect()\nor close(), atmtcp_send_control() is called to send an in-kernel\nspecial message.\n\nThe message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.\nAlso, a pointer of struct atm_vcc is set to atmtcp_control.vcc.\n\nThe notable thing is struct atmtcp_control is uAPI but has a\nspace for an in-kernel pointer.\n\n struct atmtcp_control {\n \tstruct atmtcp_hdr hdr;\t/* must be first */\n ...\n \tatm_kptr_t vcc;\t\t/* both directions */\n ...\n } __ATM_API_ALIGN;\n\n typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;\n\nThe special message is processed in atmtcp_recv_control() called\nfrom atmtcp_c_send().\n\natmtcp_c_send() is vcc-\u0026gt;dev-\u0026gt;ops-\u0026gt;send() and called from 2 paths:\n\n 1. .ndo_start_xmit() (vcc-\u0026gt;send() == atm_send_aal0())\n 2. vcc_sendmsg()\n\nThe problem is sendmsg() does not validate the message length and\nuserspace can abuse atmtcp_recv_control() to overwrite any kptr\nby atmtcp_control.\n\nLet\u0026apos;s add a new -\u0026gt;pre_send() hook to validate messages from sendmsg().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI\nKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]\nCPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]\nRIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297\nCode: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c\nRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203\nRAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c\nRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd\nR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000\nR13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff\nFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n ____sys_sendmsg+0x505/0x830 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f8d7e96a4a9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9\nRDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005\nRBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f\nR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac\nR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250\n \u0026lt;/TASK\u0026gt;\nModules linked in:(CVE-2025-39828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: prevent NULL pointer dereference in UTF16 conversion\n\nThere can be a NULL pointer dereference bug here. NULL is passed to\n__cifs_sfu_make_node without checks, which passes it unchecked to\ncifs_strndup_to_utf16, which in turn passes it to\ncifs_local_to_utf16_bytes where \u0026apos;*from\u0026apos; is dereferenced, causing a crash.\n\nThis patch adds a check for NULL \u0026apos;src\u0026apos; in cifs_strndup_to_utf16 and\nreturns NULL early to prevent dereferencing NULL pointer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix OOB read/write in network-coding decode\n\nbatadv_nc_skb_decode_packet() trusts coded_len and checks only against\nskb-\u0026gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing\npayload headroom, and the source skb length is not verified, allowing an\nout-of-bounds read and a small out-of-bounds write.\n\nValidate that coded_len fits within the payload area of both destination\nand source sk_buffs before XORing.(CVE-2025-39839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix race condition validating r_parent before applying state\n\nAdd validation to ensure the cached parent directory inode matches the\ndirectory info in MDS replies. This prevents client-side race conditions\nwhere concurrent operations (e.g. rename) cause r_parent to become stale\nbetween request initiation and reply processing, which could lead to\napplying state changes to incorrect directory inodes.\n\n[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to\n move CEPH_CAP_PIN reference when r_parent is updated:\n\n When the parent directory lock is not held, req-\u0026gt;r_parent can become\n stale and is updated to point to the correct inode. However, the\n associated CEPH_CAP_PIN reference was not being adjusted. The\n CEPH_CAP_PIN is a reference on an inode that is tracked for\n accounting purposes. Moving this pin is important to keep the\n accounting balanced. When the pin was not moved from the old parent\n to the new one, it created two problems: The reference on the old,\n stale parent was never released, causing a reference leak.\n A reference for the new parent was never acquired, creating the risk\n of a reference underflow later in ceph_mdsc_release_request(). This\n patch corrects the logic by releasing the pin from the old parent and\n acquiring it for the new parent when r_parent is switched. This\n ensures reference accounting stays balanced. ](CVE-2025-39927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path\n\nDuring tests of another unrelated patch I was able to trigger this\nerror: Objects remaining on __kmem_cache_shutdown()(CVE-2025-39929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: virtio_uml: Fix use-after-free after put_device in probe\n\nWhen register_virtio_device() fails in virtio_uml_probe(),\nthe code sets vu_dev-\u0026gt;registered = 1 even though\nthe device was not successfully registered.\nThis can lead to use-after-free or other issues.(CVE-2025-39951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix null-deref in agg_dequeue\n\nTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)\nwhen cl-\u0026gt;qdisc-\u0026gt;ops-\u0026gt;peek(cl-\u0026gt;qdisc) returns NULL, we check the return\nvalue before using it, similar to the existing approach in sch_hfsc.c.\n\nTo avoid code duplication, the following changes are made:\n\n1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static\ninline function.\n\n2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to\ninclude/net/pkt_sched.h so that sch_qfq can reuse it.\n\n3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Define a proc_layoutcommit for the FlexFiles layout type\n\nAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT\noperation on a FlexFiles layout.(CVE-2025-40087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: parse_dfs_referrals: prevent oob on malformed input\n\nMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS\n\n- reply smaller than sizeof(struct get_dfs_referral_rsp)\n- reply with number of referrals smaller than NumberOfReferrals in the\nheader\n\nProcessing of such replies will cause oob.\n\nReturn -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix refcount leak for cifs_sb_tlink\n\nFix three refcount inconsistency issues related to `cifs_sb_tlink`.\n\nComments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be\ncalled after successful calls to `cifs_sb_tlink()`. Three calls fail to\nupdate refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0026apos;t leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn\u0026apos;t point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\u0026quot;VFS: don\u0026apos;t keep disconnected dentries on d_anon\u0026quot;)\nwhich removed adding of most disconnected dentries to sb-\u0026gt;s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn\u0026apos;t marked as disconnected, as in the\nscenario described above, the reclaim doesn\u0026apos;t happen and the dentries\nare \u0026quot;leaked\u0026quot;. Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \u0026quot;Busy\ninodes after unmount\u0026quot; bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.(CVE-2025-40105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix Use-after-free in validation\n\nNodes stored in the validation duplicates hashtable come from an arena\nallocator that is cleared at the end of vmw_execbuf_process. All nodes\nare expected to be cleared in vmw_validation_drop_ht but this node escaped\nbecause its resource was destroyed prematurely.(CVE-2025-40111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Clean up only new IRQ glue on request_irq() failure\n\nThe mlx5_irq_alloc() function can inadvertently free the entire rmap\nand end up in a crash[1] when the other threads tries to access this,\nwhen request_irq() fails due to exhausted IRQ vectors. This commit\nmodifies the cleanup to remove only the specific IRQ mapping that was\njust added.\n\nThis prevents removal of other valid mappings and ensures precise\ncleanup of the failed IRQ allocation\u0026apos;s associated glue object.\n\nNote: This error is observed when both fwctl and rds configs are enabled.\n\n[1]\nmlx5_core 0000:05:00.0: Successfully registered panic handler for port 1\nmlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to\nrequest irq. err = -28\ninfiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while\ntrying to test write-combining support\nmlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1\nmlx5_core 0000:06:00.0: Successfully registered panic handler for port 1\nmlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to\nrequest irq. err = -28\ninfiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while\ntrying to test write-combining support\nmlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1\nmlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to\nrequest irq. err = -28\nmlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to\nrequest irq. err = -28\ngeneral protection fault, probably for non-canonical address\n0xe277a58fde16f291: 0000 [#1] SMP NOPTI\n\nRIP: 0010:free_irq_cpu_rmap+0x23/0x7d\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_trace_log_lvl+0x1d6/0x2f9\n ? show_trace_log_lvl+0x1d6/0x2f9\n ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]\n ? __die_body.cold+0x8/0xa\n ? die_addr+0x39/0x53\n ? exc_general_protection+0x1c4/0x3e9\n ? dev_vprintk_emit+0x5f/0x90\n ? asm_exc_general_protection+0x22/0x27\n ? free_irq_cpu_rmap+0x23/0x7d\n mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]\n irq_pool_request_vector+0x7d/0x90 [mlx5_core]\n mlx5_irq_request+0x2e/0xe0 [mlx5_core]\n mlx5_irq_request_vector+0xad/0xf7 [mlx5_core]\n comp_irq_request_pci+0x64/0xf0 [mlx5_core]\n create_comp_eq+0x71/0x385 [mlx5_core]\n ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core]\n mlx5_comp_eqn_get+0x72/0x90 [mlx5_core]\n ? xas_load+0x8/0x91\n mlx5_comp_irqn_get+0x40/0x90 [mlx5_core]\n mlx5e_open_channel+0x7d/0x3c7 [mlx5_core]\n mlx5e_open_channels+0xad/0x250 [mlx5_core]\n mlx5e_open_locked+0x3e/0x110 [mlx5_core]\n mlx5e_open+0x23/0x70 [mlx5_core]\n __dev_open+0xf1/0x1a5\n __dev_change_flags+0x1e1/0x249\n dev_change_flags+0x21/0x5c\n do_setlink+0x28b/0xcc4\n ? __nla_parse+0x22/0x3d\n ? inet6_validate_link_af+0x6b/0x108\n ? cpumask_next+0x1f/0x35\n ? __snmp6_fill_stats64.constprop.0+0x66/0x107\n ? __nla_validate_parse+0x48/0x1e6\n __rtnl_newlink+0x5ff/0xa57\n ? kmem_cache_alloc_trace+0x164/0x2ce\n rtnl_newlink+0x44/0x6e\n rtnetlink_rcv_msg+0x2bb/0x362\n ? __netlink_sendskb+0x4c/0x6c\n ? netlink_unicast+0x28f/0x2ce\n ? rtnl_calcit.isra.0+0x150/0x146\n netlink_rcv_skb+0x5f/0x112\n netlink_unicast+0x213/0x2ce\n netlink_sendmsg+0x24f/0x4d9\n __sock_sendmsg+0x65/0x6a\n ____sys_sendmsg+0x28f/0x2c9\n ? import_iovec+0x17/0x2b\n ___sys_sendmsg+0x97/0xe0\n __sys_sendmsg+0x81/0xd8\n do_syscall_64+0x35/0x87\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\nRIP: 0033:0x7fc328603727\nCode: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed\nff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00\nf0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48\nRSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727\nRDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d\nRBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\nR13: 00000000000\n---truncated---(CVE-2025-40250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()\n\nThe loops in \u0026apos;qede_tpa_cont()\u0026apos; and \u0026apos;qede_tpa_end()\u0026apos;, iterate\nover \u0026apos;cqe-\u0026gt;len_list[]\u0026apos; using only a zero-length terminator as\nthe stopping condition. If the terminator was missing or\nmalformed, the loop could run past the end of the fixed-size array.\n\nAdd an explicit bound check using ARRAY_SIZE() in both loops to prevent\na potential out-of-bounds access.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Do not sleep in atomic context\n\nsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may\nsleep. Hence, call sg_finish_rem_req() with interrupts enabled instead\nof disabled.(CVE-2025-40259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: nvme-fc: Ensure -\u0026gt;ioerr_work is cancelled in nvme_fc_delete_ctrl()\n\nnvme_fc_delete_assocation() waits for pending I/O to complete before\nreturning, and an error can cause -\u0026gt;ioerr_work to be queued after\ncancel_work_sync() had been called. Move the call to cancel_work_sync() to\nbe after nvme_fc_delete_association() to ensure -\u0026gt;ioerr_work is not running\nwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:\n\n[ 1135.911754] list_del corruption, ff2d24c8093f31f8-\u0026gt;next is NULL\n[ 1135.917705] ------------[ cut here ]------------\n[ 1135.922336] kernel BUG at lib/list_debug.c:52!\n[ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)\n[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025\n[ 1135.950969] Workqueue: 0x0 (nvme-wq)\n[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b\n[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046\n[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000\n[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0\n[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08\n[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100\n[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0\n[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000\n[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0\n[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[ 1136.055910] PKRU: 55555554\n[ 1136.058623] Call Trace:\n[ 1136.061074] \u0026lt;TASK\u0026gt;\n[ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.071898] ? move_linked_works+0x4a/0xa0\n[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.081744] ? __die_body.cold+0x8/0x12\n[ 1136.085584] ? die+0x2e/0x50\n[ 1136.088469] ? do_trap+0xca/0x110\n[ 1136.091789] ? do_error_trap+0x65/0x80\n[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.101289] ? exc_invalid_op+0x50/0x70\n[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20\n[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.120806] move_linked_works+0x4a/0xa0\n[ 1136.124733] worker_thread+0x216/0x3a0\n[ 1136.128485] ? __pfx_worker_thread+0x10/0x10\n[ 1136.132758] kthread+0xfa/0x240\n[ 1136.135904] ? __pfx_kthread+0x10/0x10\n[ 1136.139657] ret_from_fork+0x31/0x50\n[ 1136.143236] ? __pfx_kthread+0x10/0x10\n[ 1136.146988] ret_from_fork_asm+0x1a/0x30\n[ 1136.150915] \u0026lt;/TASK\u0026gt;(CVE-2025-40261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: pass wrb_params in case of OS2BMC\n\nbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULL\nat be_send_pkt_to_bmc() call site.\u00a0 This may lead to dereferencing a NULL\npointer when processing a workaround for specific packet, as commit\nbc0c3405abbb (\u0026quot;be2net: fix a Tx stall bug caused by a specific ipv6\npacket\u0026quot;) states.\n\nThe correct way would be to pass the wrb_params from be_xmit().(CVE-2025-40264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: client: fix memory leak in smb3_fs_context_parse_param\n\nThe user calls fsconfig twice, but when the program exits, free() only\nfrees ctx-\u0026gt;source for the second fsconfig, not the first.\nRegarding fc-\u0026gt;source, there is no code in the fs context related to its\nmemory reclamation.\n\nTo fix this memory leak, release the source memory corresponding to ctx\nor fc before each parsing.\n\nsyzbot reported:\nBUG: memory leak\nunreferenced object 0xffff888128afa360 (size 96):\n backtrace (crc 79c9c7ba):\n kstrdup+0x3c/0x80 mm/util.c:84\n smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444\n\nBUG: memory leak\nunreferenced object 0xffff888112c7d900 (size 96):\n backtrace (crc 79c9c7ba):\n smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629\n smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: free copynotify stateid in nfs4_free_ol_stateid()\n\nTypically copynotify stateid is freed either when parent\u0026apos;s stateid\nis being close/freed or in nfsd4_laundromat if the stateid hasn\u0026apos;t\nbeen used in a lease period.\n\nHowever, in case when the server got an OPEN (which created\na parent stateid), followed by a COPY_NOTIFY using that stateid,\nfollowed by a client reboot. New client instance while doing\nCREATE_SESSION would force expire previous state of this client.\nIt leads to the open state being freed thru release_openowner-\u0026gt;\nnfs4_free_ol_stateid() and it finds that it still has copynotify\nstateid associated with it. We currently print a warning and is\ntriggerred\n\nWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]\n\nThis patch, instead, frees the associated copynotify stateid here.\n\nIf the parent stateid is freed (without freeing the copynotify\nstateids associated with it), it leads to the list corruption\nwhen laundromat ends up freeing the copynotify state later.\n\n[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink\n[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)\n[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN\n[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024\n[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd]\n[ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.861182] sp : ffff8000881d7a40\n[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200\n[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20\n[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8\n[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000\n[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065\n[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3\n[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000\n[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001\n[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000\n[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d\n[ 1626.868167] Call trace:\n[ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)\n[ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd]\n[ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd]\n[ 1626.869813] laundromat_main+0x24/0x60 [nfsd]\n[ 1626.870231] process_one_work+0x584/0x1050\n[ 1626.870595] worker_thread+0x4c4/0xc60\n[ 1626.870893] kthread+0x2f8/0x398\n[ 1626.871146] ret_from_fork+0x10/0x20\n[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)\n[ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: cancel mesh send timer when hdev removed\n\nmesh_send_done timer is not canceled when hdev is removed, which causes\ncrash if the timer triggers after hdev is gone.\n\nCancel the timer when MGMT removes the hdev, like other MGMT timers.\n\nShould fix the BUG: sporadically seen by BlueZ test bot\n(in \u0026quot;Mesh - Send cancel - 1\u0026quot; test).\n\nLog:\n------\nBUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0\n...\nFreed by task 36:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3a/0x60\n __kasan_slab_free+0x43/0x70\n kfree+0x103/0x500\n device_release+0x9a/0x210\n kobject_put+0x100/0x1e0\n vhci_release+0x18b/0x240\n------(CVE-2025-40284)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds\n\nAdd bounds checking to prevent writes past framebuffer boundaries when\nrendering text near screen edges. Return early if the Y position is off-screen\nand clip image height to screen boundary. Break from the rendering loop if the\nX position is off-screen. When clipping image width to fit the screen, update\nthe character count to match the clipped width to prevent buffer size\nmismatches.\n\nWithout the character count update, bit_putcs_aligned and bit_putcs_unaligned\nreceive mismatched parameters where the buffer is allocated for the clipped\nwidth but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naccel/habanalabs: support mapping cb with vmalloc-backed coherent memory\n\nWhen IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return\naddresses from the vmalloc range. If such an address is mapped without\nVM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the\nVM_PFNMAP restriction.\n\nFix this by checking for vmalloc addresses and setting VM_MIXEDMAP\nin the VMA before mapping. This ensures safe mapping and avoids kernel\ncrashes. The memory is still driver-allocated and cannot be accessed\ndirectly by userspace.(CVE-2025-40311)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget\n\nIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget\nstructure (pdev-\u0026gt;gadget) was freed before its endpoints.\nThe endpoints are linked via the ep_list in the gadget structure.\nFreeing the gadget first leaves dangling pointers in the endpoint list.\nWhen the endpoints are subsequently freed, this results in a use-after-free.\n\nFix:\nBy separating the usb_del_gadget_udc() operation into distinct \u0026quot;del\u0026quot; and\n\u0026quot;put\u0026quot; steps, cdnsp_gadget_free_endpoints() can be executed prior to the\nfinal release of the gadget structure with usb_put_gadget().\n\nA patch similar to bb9c74a5bd14(\u0026quot;usb: dwc3: gadget: Free gadget structure\n only after freeing endpoints\u0026quot;).(CVE-2025-40314)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Sync pending IRQ work before freeing ring buffer\n\nFix a race where irq_work can be queued in bpf_ringbuf_commit()\nbut the ring buffer is freed before the work executes.\nIn the syzbot reproducer, a BPF program attached to sched_switch\ntriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer\nis freed before this work executes, the irq_work thread may accesses\nfreed memory.\nCalling `irq_work_sync(\u0026amp;rb-\u0026gt;work)` ensures that all pending irq_work\ncomplete before freeing the buffer.(CVE-2025-40319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential cfid UAF in smb2_query_info_compound\n\nWhen smb2_query_info_compound() retries, a previously allocated cfid may\nhave been freed in the first attempt.\nBecause cfid wasn\u0026apos;t reset on replay, later cleanup could act on a stale\npointer, leading to a potential use-after-free.\n\nReinitialize cfid to NULL under the replay label.\n\nExample trace (trimmed):\n\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110\n[...]\nRIP: 0010:refcount_warn_saturate+0x9c/0x110\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n ? step_into+0x10d/0x690\n ? __legitimize_path+0x28/0x60\n smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n ? kmem_cache_alloc+0x18a/0x340\n ? getname_flags+0x46/0x1e0\n cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n statfs_by_dentry+0x67/0x90\n vfs_statfs+0x16/0xd0\n user_statfs+0x54/0xa0\n __do_sys_statfs+0x20/0x50\n do_syscall_64+0x58/0x80(CVE-2025-40320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: bitblit: bound-check glyph index in bit_putcs*\n\nbit_putcs_aligned()/unaligned() derived the glyph pointer from the\ncharacter value masked by 0xff/0x1ff, which may exceed the actual font\u0026apos;s\nglyph count and read past the end of the built-in font array.\nClamp the index to the actual glyph count before computing the address.\n\nThis fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Fix crash in nfsd4_read_release()\n\nWhen tracing is enabled, the trace_nfsd_read_done trace point\ncrashes during the pynfs read.testNoFh test.(CVE-2025-40324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in smb2_close_cached_fid()\n\nfind_or_create_cached_dir() could grab a new reference after kref_put()\nhad seen the refcount drop to zero but before cfid_list_lock is acquired\nin smb2_close_cached_fid(), leading to use-after-free.\n\nSwitch to kref_put_lock() so cfid_release() is called with\ncfid_list_lock held, closing that gap.(CVE-2025-40328)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: sddr55: Reject out-of-bound new_pba\n\nDiscovered by Atuin - Automated Vulnerability Discovery Engine.\n\nnew_pba comes from the status packet returned after each write.\nA bogus device could report values beyond the block count derived\nfrom info-\u0026gt;capacity, letting the driver walk off the end of\npba_to_lba[] and corrupt heap memory.\n\nReject PBAs that exceed the computed block count and fail the\ntransfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ\n\nXDP programs can change the layout of an xdp_buff through\nbpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver\ncannot assume the size of the linear data area nor fragments. Fix the\nbug in mlx5 by generating skb according to xdp_buff after XDP programs\nrun.\n\nCurrently, when handling multi-buf XDP, the mlx5 driver assumes the\nlayout of an xdp_buff to be unchanged. That is, the linear data area\ncontinues to be empty and fragments remain the same. This may cause\nthe driver to generate erroneous skb or triggering a kernel\nwarning. When an XDP program added linear data through\nbpf_xdp_adjust_head(), the linear data will be ignored as\nmlx5e_build_linear_skb() builds an skb without linear data and then\npull data from fragments to fill the linear data area. When an XDP\nprogram has shrunk the non-linear data through bpf_xdp_adjust_tail(),\nthe delta passed to __pskb_pull_tail() may exceed the actual nonlinear\ndata size and trigger the BUG_ON in it.\n\nTo fix the issue, first record the original number of fragments. If the\nnumber of fragments changes after the XDP program runs, rewind the end\nfragment pointer by the difference and recalculate the truesize. Then,\nbuild the skb with the linear data area matching the xdp_buff. Finally,\nonly pull data in if there is non-linear data and fill the linear part\nup to 256 bytes.(CVE-2025-40350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sysfb: Do not dereference NULL pointer in plane reset\n\nThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not\nderef that pointer, but forward NULL to the other plane-reset helpers.\nClears plane-\u0026gt;state to NULL.\n\nv2:\n- fix typo in commit description (Javier)(CVE-2025-40360)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: fix field-spanning memcpy warning in AH output\n\nFix field-spanning memcpy warnings in ah6_output() and\nah6_output_done() where extension headers are copied to/from IPv6\naddress fields, triggering fortify-string warnings about writes beyond\nthe 16-byte address fields.\n\n memcpy: detected field-spanning write (size 40) of single field \u0026quot;\u0026amp;top_iph-\u0026gt;saddr\u0026quot; at net/ipv6/ah6.c:439 (size 16)\n WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439\n\nThe warnings are false positives as the extension headers are\nintentionally placed after the IPv6 header in memory. Fix by properly\ncopying addresses and extension headers separately, and introduce\nhelper functions to avoid code duplication.(CVE-2025-40363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix possible deadlock while configuring policy\n\nFollowing deadlock can be triggered easily by lockdep:\n\nWARNING: possible circular locking dependency detected\n6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted\n------------------------------------------------------\ncheck/1334 is trying to acquire lock:\nff1100011d9d0678 (\u0026amp;q-\u0026gt;sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180\n\nbut task is already holding lock:\nff1100011d9d00e0 (\u0026amp;q-\u0026gt;q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;q-\u0026gt;q_usage_counter(queue)#3){++++}-{0:0}:\n blk_queue_enter+0x40b/0x470\n blkg_conf_prep+0x7b/0x3c0\n tg_set_limit+0x10a/0x3e0\n cgroup_file_write+0xc6/0x420\n kernfs_fop_write_iter+0x189/0x280\n vfs_write+0x256/0x490\n ksys_write+0x83/0x190\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x4608/0x4630\n do_syscall_64+0xdb/0x6b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #1 (\u0026amp;q-\u0026gt;rq_qos_mutex){+.+.}-{4:4}:\n __mutex_lock+0xd8/0xf50\n mutex_lock_nested+0x2b/0x40\n wbt_init+0x17e/0x280\n wbt_enable_default+0xe9/0x140\n blk_register_queue+0x1da/0x2e0\n __add_disk+0x38c/0x5d0\n add_disk_fwnode+0x89/0x250\n device_add_disk+0x18/0x30\n virtblk_probe+0x13a3/0x1800\n virtio_dev_probe+0x389/0x610\n really_probe+0x136/0x620\n __driver_probe_device+0xb3/0x230\n driver_probe_device+0x2f/0xe0\n __driver_attach+0x158/0x250\n bus_for_each_dev+0xa9/0x130\n driver_attach+0x26/0x40\n bus_add_driver+0x178/0x3d0\n driver_register+0x7d/0x1c0\n __register_virtio_driver+0x2c/0x60\n virtio_blk_init+0x6f/0xe0\n do_one_initcall+0x94/0x540\n kernel_init_freeable+0x56a/0x7b0\n kernel_init+0x2b/0x270\n ret_from_fork+0x268/0x4c0\n ret_from_fork_asm+0x1a/0x30\n\n-\u0026gt; #0 (\u0026amp;q-\u0026gt;sysfs_lock){+.+.}-{4:4}:\n __lock_acquire+0x1835/0x2940\n lock_acquire+0xf9/0x450\n __mutex_lock+0xd8/0xf50\n mutex_lock_nested+0x2b/0x40\n blk_unregister_queue+0x53/0x180\n __del_gendisk+0x226/0x690\n del_gendisk+0xba/0x110\n sd_remove+0x49/0xb0 [sd_mod]\n device_remove+0x87/0xb0\n device_release_driver_internal+0x11e/0x230\n device_release_driver+0x1a/0x30\n bus_remove_device+0x14d/0x220\n device_del+0x1e1/0x5a0\n __scsi_remove_device+0x1ff/0x2f0\n scsi_remove_device+0x37/0x60\n sdev_store_delete+0x77/0x100\n dev_attr_store+0x1f/0x40\n sysfs_kf_write+0x65/0x90\n kernfs_fop_write_iter+0x189/0x280\n vfs_write+0x256/0x490\n ksys_write+0x83/0x190\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x4608/0x4630\n do_syscall_64+0xdb/0x6b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nother info that might help us debug this:\n\nChain exists of:\n \u0026amp;q-\u0026gt;sysfs_lock --\u0026gt; \u0026amp;q-\u0026gt;rq_qos_mutex --\u0026gt; \u0026amp;q-\u0026gt;q_usage_counter(queue)#3\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;q-\u0026gt;q_usage_counter(queue)#3);\n lock(\u0026amp;q-\u0026gt;rq_qos_mutex);\n lock(\u0026amp;q-\u0026gt;q_usage_counter(queue)#3);\n lock(\u0026amp;q-\u0026gt;sysfs_lock);\n\nRoot cause is that queue_usage_counter is grabbed with rq_qos_mutex\nheld in blkg_conf_prep(), while queue should be freezed before\nrq_qos_mutex from other context.\n\nThe blk_queue_enter() from blkg_conf_prep() is used to protect against\npolicy deactivation, which is already protected with blkcg_mutex, hence\nconvert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,\nconsider that blkcg_mutex is held after queue is freezed from policy\ndeactivation, also convert blkg_alloc() to use GFP_NOIO.(CVE-2025-68178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Disable AFBC support on Mediatek DRM driver\n\nCommit c410fa9b07c3 (\u0026quot;drm/mediatek: Add AFBC support to Mediatek DRM\ndriver\u0026quot;) added AFBC support to Mediatek DRM and enabled the\n32x8/split/sparse modifier.\n\nHowever, this is currently broken on Mediatek MT8188 (Genio 700 EVK\nplatform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by\ndefault since Mesa v25.0.\n\nKernel trace reports vblank timeouts constantly, and the render is garbled:\n\n```\n[CRTC:62:crtc-0] vblank wait timed out\nWARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\n[...]\nHardware name: MediaTek Genio-700 EVK (DT)\nWorkqueue: events_unbound commit_work\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nlr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nsp : ffff80008337bca0\nx29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000\nx26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000\nx23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80\nx20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a\nx17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000\nx14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b\nx11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70\nx8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70\nx5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480\nCall trace:\n drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)\n drm_atomic_helper_commit_tail_rpm+0x64/0x80\n commit_tail+0xa4/0x1a4\n commit_work+0x14/0x20\n process_one_work+0x150/0x290\n worker_thread+0x2d0/0x3ec\n kthread+0x12c/0x210\n ret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\n```\n\nUntil this gets fixed upstream, disable AFBC support on this platform, as\nit\u0026apos;s currently broken with upstream Mesa.(CVE-2025-68184)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs4_setup_readdir(): insufficient locking for -\u0026gt;d_parent-\u0026gt;d_inode dereferencing\n\nTheoretically it\u0026apos;s an oopsable race, but I don\u0026apos;t believe one can manage\nto hit it on real hardware; might become doable on a KVM, but it still\nwon\u0026apos;t be easy to attack.\n\nAnyway, it\u0026apos;s easy to deal with - since xdr_encode_hyper() is just a call of\nput_unaligned_be64(), we can put that under -\u0026gt;d_lock and be done with that.(CVE-2025-68185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp_tunnel: use netdev_warn() instead of netdev_WARN()\n\nnetdev_WARN() uses WARN/WARN_ON to print a backtrace along with\nfile and line information. In this case, udp_tunnel_nic_register()\nreturning an error is just a failed operation, not a kernel bug.\n\nudp_tunnel_nic_register() can fail due to a memory allocation\nfailure (kzalloc() or udp_tunnel_nic_alloc()).\nThis is a normal runtime error and not a kernel bug.\n\nReplace netdev_WARN() with netdev_warn() accordingly.(CVE-2025-68191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: fix lockdep WARN due to partition scan work\n\nBlktests test cases nvme/014, 057 and 058 fail occasionally due to a\nlockdep WARN. As reported in the Closes tag URL, the WARN indicates that\na deadlock can happen due to the dependency among disk-\u0026gt;open_mutex,\nkblockd workqueue completion and partition_scan_work completion.\n\nTo avoid the lockdep WARN and the potential deadlock, cut the dependency\nby running the partition_scan_work not by kblockd workqueue but by\nnvme_wq.(CVE-2025-68218)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix memory leak in smb3_fs_context_parse_param error path\n\nAdd proper cleanup of ctx-\u0026gt;source and fc-\u0026gt;source to the\ncifs_parse_mount_err error handler. This ensures that memory allocated\nfor the source strings is correctly freed on all error paths, matching\nthe cleanup already performed in the success path by\nsmb3_cleanup_fs_context_contents().\nPointers are also set to NULL after freeing to prevent potential\ndouble-free issues.\n\nThis change fixes a memory leak originally detected by syzbot. The\nleak occurred when processing Opt_source mount options if an error\nhappened after ctx-\u0026gt;source and fc-\u0026gt;source were successfully\nallocated but before the function completed.\n\nThe specific leak sequence was:\n1. ctx-\u0026gt;source = smb3_fs_context_fullpath(ctx, \u0026apos;/\u0026apos;) allocates memory\n2. fc-\u0026gt;source = kstrdup(ctx-\u0026gt;source, GFP_KERNEL) allocates more memory\n3. A subsequent error jumps to cifs_parse_mount_err\n4. The old error handler freed passwords but not the source strings,\ncausing the memory to leak.\n\nThis issue was not addressed by commit e8c73eb7db0a (\u0026quot;cifs: client:\nfix memory leak in smb3_fs_context_parse_param\u0026quot;), which only fixed\nleaks from repeated fsconfig() calls but not this error path.\n\nPatch updated with minor change suggested by kernel test robot(CVE-2025-68219)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()\n\nIf the allocation of tl_hba-\u0026gt;sh fails in tcm_loop_driver_probe() and we\nattempt to dereference it in tcm_loop_tpg_address_show() we will get a\nsegfault, see below for an example. So, check tl_hba-\u0026gt;sh before\ndereferencing it.\n\n Unable to allocate struct scsi_host\n BUG: kernel NULL pointer dereference, address: 0000000000000194\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1\n Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024\n RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]\n...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n configfs_read_iter+0x12d/0x1d0 [configfs]\n vfs_read+0x1b5/0x300\n ksys_read+0x6f/0xf0\n...(CVE-2025-68229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: restore write access before closing files opened by open_exec()\n\nbm_register_write() opens an executable file using open_exec(), which\ninternally calls do_open_execat() and denies write access on the file to\navoid modification while it is being executed.\n\nHowever, when an error occurs, bm_register_write() closes the file using\nfilp_close() directly. This does not restore the write permission, which\nmay cause subsequent write operations on the same file to fail.\n\nFix this by calling exe_file_allow_write_access() before filp_close() to\nrestore the write permission properly.(CVE-2025-68239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe\n\nThe sit driver\u0026apos;s packet transmission path calls: sit_tunnel_xmit() -\u0026gt;\nupdate_or_create_fnhe(), which lead to fnhe_remove_oldest() being called\nto delete entries exceeding FNHE_RECLAIM_DEPTH+random.\n\nThe race window is between fnhe_remove_oldest() selecting fnheX for\ndeletion and the subsequent kfree_rcu(). During this time, the\nconcurrent path\u0026apos;s __mkroute_output() -\u0026gt; find_exception() can fetch the\nsoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a\nnew dst using a dst_hold(). When the original fnheX is freed via RCU,\nthe dst reference remains permanently leaked.\n\nCPU 0 CPU 1\n__mkroute_output()\n find_exception() [fnheX]\n update_or_create_fnhe()\n fnhe_remove_oldest() [fnheX]\n rt_bind_exception() [bind dst]\n RCU callback [fnheX freed, dst leak]\n\nThis issue manifests as a device reference count leak and a warning in\ndmesg when unregistering the net device:\n\n unregister_netdevice: waiting for sitX to become free. Usage count = N\n\nIdo Schimmel provided the simple test validation method [1].\n\nThe fix clears \u0026apos;oldest-\u0026gt;fnhe_daddr\u0026apos; before calling fnhe_flush_routes().\nSince rt_bind_exception() checks this field, setting it to zero prevents\nthe stale fnhe from being reused and bound to a new dst just before it\nis freed.\n\n[1]\nip netns add ns1\nip -n ns1 link set dev lo up\nip -n ns1 address add 192.0.2.1/32 dev lo\nip -n ns1 link add name dummy1 up type dummy\nip -n ns1 route add 192.0.2.2/32 dev dummy1\nip -n ns1 link add name gretap1 up arp off type gretap \\\n local 192.0.2.1 remote 192.0.2.2\nip -n ns1 route add 198.51.0.0/16 dev gretap1\ntaskset -c 0 ip netns exec ns1 mausezahn gretap1 \\\n -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q \u0026amp;\ntaskset -c 2 ip netns exec ns1 mausezahn gretap1 \\\n -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q \u0026amp;\nsleep 10\nip netns pids ns1 | xargs kill\nip netns del ns1(CVE-2025-68241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: netpoll: fix incorrect refcount handling causing incorrect cleanup\n\ncommit efa95b01da18 (\u0026quot;netpoll: fix use after free\u0026quot;) incorrectly\nignored the refcount and prematurely set dev-\u0026gt;npinfo to NULL during\nnetpoll cleanup, leading to improper behavior and memory leaks.\n\nScenario causing lack of proper cleanup:\n\n1) A netpoll is associated with a NIC (e.g., eth0) and netdev-\u0026gt;npinfo is\n allocated, and refcnt = 1\n - Keep in mind that npinfo is shared among all netpoll instances. In\n this case, there is just one.\n\n2) Another netpoll is also associated with the same NIC and\n npinfo-\u0026gt;refcnt += 1.\n - Now dev-\u0026gt;npinfo-\u0026gt;refcnt = 2;\n - There is just one npinfo associated to the netdev.\n\n3) When the first netpolls goes to clean up:\n - The first cleanup succeeds and clears np-\u0026gt;dev-\u0026gt;npinfo, ignoring\n refcnt.\n - It basically calls `RCU_INIT_POINTER(np-\u0026gt;dev-\u0026gt;npinfo, NULL);`\n - Set dev-\u0026gt;npinfo = NULL, without proper cleanup\n - No -\u0026gt;ndo_netpoll_cleanup() is either called\n\n4) Now the second target tries to clean up\n - The second cleanup fails because np-\u0026gt;dev-\u0026gt;npinfo is already NULL.\n * In this case, ops-\u0026gt;ndo_netpoll_cleanup() was never called, and\n the skb pool is not cleaned as well (for the second netpoll\n instance)\n - This leaks npinfo and skbpool skbs, which is clearly reported by\n kmemleak.\n\nRevert commit efa95b01da18 (\u0026quot;netpoll: fix use after free\u0026quot;) and adds\nclarifying comments emphasizing that npinfo cleanup should only happen\nonce the refcount reaches zero, ensuring stable and correct netpoll\nbehavior.(CVE-2025-68245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: avoid infinite loops due to corrupted subpage compact indexes\n\nRobert reported an infinite loop observed by two crafted images.\n\nThe root cause is that `clusterofs` can be larger than `lclustersize`\nfor !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:\n\n blocksize = lclustersize = 512 lcn = 6 clusterofs = 515\n\nMove the corresponding check for full compress indexes to\n`z_erofs_load_lcluster_from_disk()` to also cover subpage compact\ncompress indexes.\n\nIt also fixes the position of `m-\u0026gt;type \u0026gt;= Z_EROFS_LCLUSTER_TYPE_MAX`\ncheck, since it should be placed right after\n`z_erofs_load_{compact,full}_lcluster()`.(CVE-2025-68251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: Fix memory leak in USB bulk transport\n\nA kernel memory leak was identified by the \u0026apos;ioctl_sg01\u0026apos; test from Linux\nTest Project (LTP). The following bytes were mainly observed: 0x53425355.\n\nWhen USB storage devices incorrectly skip the data phase with status data,\nthe code extracts/validates the CSW from the sg buffer, but fails to clear\nit afterwards. This leaves status protocol data in srb\u0026apos;s transfer buffer,\nsuch as the US_BULK_CS_SIGN \u0026apos;USBS\u0026apos; signature observed here. Thus, this can\nlead to USB protocols leaks to user space through SCSI generic (/dev/sg*)\ninterfaces, such as the one seen here when the LTP test requested 512 KiB.\n\nFix the leak by zeroing the CSW data in srb\u0026apos;s transfer buffer immediately\nafter the validation of devices that skip data phase.\n\nNote: Differently from CVE-2018-1000204, which fixed a big leak by zero-\ning pages at allocation time, this leak occurs after allocation, when USB\nprotocol data is written to already-allocated sg pages.(CVE-2025-68288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix memory leak in cifs_construct_tcon()\n\nWhen having a multiuser mount with domain= specified and using\ncifscreds, cifs_set_cifscreds() will end up setting @ctx-\u0026gt;domainname,\nso it needs to be freed before leaving cifs_construct_tcon().\n\nThis fixes the following memory leak reported by kmemleak:\n\n mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...\n su - testuser\n cifscreds add -d ZELDA -u testuser\n ...\n ls /mnt/1\n ...\n umount /mnt\n echo scan \u0026gt; /sys/kernel/debug/kmemleak\n cat /sys/kernel/debug/kmemleak\n unreferenced object 0xffff8881203c3f08 (size 8):\n comm \u0026quot;ls\u0026quot;, pid 5060, jiffies 4307222943\n hex dump (first 8 bytes):\n 5a 45 4c 44 41 00 cc cc ZELDA...\n backtrace (crc d109a8cf):\n __kmalloc_node_track_caller_noprof+0x572/0x710\n kstrdup+0x3a/0x70\n cifs_sb_tlink+0x1209/0x1770 [cifs]\n cifs_get_fattr+0xe1/0xf50 [cifs]\n cifs_get_inode_info+0xb5/0x240 [cifs]\n cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]\n cifs_getattr+0x28e/0x450 [cifs]\n vfs_getattr_nosec+0x126/0x180\n vfs_statx+0xf6/0x220\n do_statx+0xab/0x110\n __x64_sys_statx+0xd5/0x130\n do_syscall_64+0xbb/0x380\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-68295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup\n\nProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOB\naccess in fbcon_remap_all(). Without holding the console lock the call\nraces with switching outputs.\n\nVGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon\nfunction uses struct fb_info.node, which is set by register_framebuffer().\nAs the fb-helper code currently sets up VGA switcheroo before registering\nthe framebuffer, the value of node is -1 and therefore not a legal value.\nFor example, fbcon uses the value within set_con2fb_map() [1] as an index\ninto an array.\n\nMoving vga_switcheroo_client_fb_set() after register_framebuffer() can\nresult in VGA switching that does not switch fbcon correctly.\n\nTherefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),\nwhich already holds the console lock. Fbdev calls fbcon_fb_registered()\nfrom within register_framebuffer(). Serializes the helper with VGA\nswitcheroo\u0026apos;s call to fbcon_remap_all().\n\nAlthough vga_switcheroo_client_fb_set() takes an instance of struct fb_info\nas parameter, it really only needs the contained fbcon state. Moving the\ncall to fbcon initialization is therefore cleaner than before. Only amdgpu,\ni915, nouveau and radeon support vga_switcheroo. For all other drivers,\nthis change does nothing.(CVE-2025-68296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sock: Prevent race in socket write iter and sock bind\n\nThere is a potential race condition between sock bind and socket write\niter. bind may free the same cmd via mgmt_pending before write iter sends\nthe cmd, just as syzbot reported in UAF[1].\n\nHere we use hci_dev_lock to synchronize the two, thereby avoiding the\nUAF mentioned in [1].\n\n[1]\nsyzbot reported:\nBUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316\nRead of size 8 at addr ffff888077164818 by task syz.0.17/5989\nCall Trace:\n mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316\n set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n sock_write_iter+0x279/0x360 net/socket.c:1195\n\nAllocated by task 5989:\n mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296\n set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n sock_write_iter+0x279/0x360 net/socket.c:1195\n\nFreed by task 5991:\n mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]\n mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257\n mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477\n hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump\n\nDo not block PCI config accesses through pci_cfg_access_lock() when\nexecuting the s390 variant of PCI error recovery: Acquire just\ndevice_lock() instead of pci_dev_lock() as powerpc\u0026apos;s EEH and\ngenerig PCI AER processing do.\n\nDuring error recovery testing a pair of tasks was reported to be hung:\n\nmlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working\nINFO: task kmcheck:72 blocked for more than 122 seconds.\n Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000\nCall Trace:\n [\u0026lt;000000065256f030\u0026gt;] __schedule+0x2a0/0x590\n [\u0026lt;000000065256f356\u0026gt;] schedule+0x36/0xe0\n [\u0026lt;000000065256f572\u0026gt;] schedule_preempt_disabled+0x22/0x30\n [\u0026lt;0000000652570a94\u0026gt;] __mutex_lock.constprop.0+0x484/0x8a8\n [\u0026lt;000003ff800673a4\u0026gt;] mlx5_unload_one+0x34/0x58 [mlx5_core]\n [\u0026lt;000003ff8006745c\u0026gt;] mlx5_pci_err_detected+0x94/0x140 [mlx5_core]\n [\u0026lt;0000000652556c5a\u0026gt;] zpci_event_attempt_error_recovery+0xf2/0x398\n [\u0026lt;0000000651b9184a\u0026gt;] __zpci_event_error+0x23a/0x2c0\nINFO: task kworker/u1664:6:1514 blocked for more than 122 seconds.\n Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000\nWorkqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]\nCall Trace:\n [\u0026lt;000000065256f030\u0026gt;] __schedule+0x2a0/0x590\n [\u0026lt;000000065256f356\u0026gt;] schedule+0x36/0xe0\n [\u0026lt;0000000652172e28\u0026gt;] pci_wait_cfg+0x80/0xe8\n [\u0026lt;0000000652172f94\u0026gt;] pci_cfg_access_lock+0x74/0x88\n [\u0026lt;000003ff800916b6\u0026gt;] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core]\n [\u0026lt;000003ff80098824\u0026gt;] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core]\n [\u0026lt;000003ff80074b62\u0026gt;] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core]\n [\u0026lt;0000000652512242\u0026gt;] devlink_health_do_dump.part.0+0x82/0x168\n [\u0026lt;0000000652513212\u0026gt;] devlink_health_report+0x19a/0x230\n [\u0026lt;000003ff80075a12\u0026gt;] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]\n\nNo kernel log of the exact same error with an upstream kernel is\navailable - but the very same deadlock situation can be constructed there,\ntoo:\n\n- task: kmcheck\n mlx5_unload_one() tries to acquire devlink lock while the PCI error\n recovery code has set pdev-\u0026gt;block_cfg_access by way of\n pci_cfg_access_lock()\n- task: kworker\n mlx5_crdump_collect() tries to set block_cfg_access through\n pci_cfg_access_lock() while devlink_health_report() had acquired\n the devlink lock.\n\nA similar deadlock situation can be reproduced by requesting a\ncrdump with\n \u0026gt; devlink health dump show pci/\u0026lt;BDF\u0026gt; reporter fw_fatal\n\nwhile PCI error recovery is executed on the same \u0026lt;BDF\u0026gt; physical function\nby mlx5_core\u0026apos;s pci_error_handlers. On s390 this can be injected with\n \u0026gt; zpcictl --reset-fw \u0026lt;BDF\u0026gt;\n\nTests with this patch failed to reproduce that second deadlock situation,\nthe devlink command is rejected with \u0026quot;kernel answers: Permission denied\u0026quot; -\nand we get a kernel log message of:\n\nmlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5\n\nbecause the config read of VSC_SEMAPHORE is rejected by the underlying\nhardware.\n\nTwo prior attempts to address this issue have been discussed and\nultimately rejected [see link], with the primary argument that s390\u0026apos;s\nimplementation of PCI error recovery is imposing restrictions that\nneither powerpc\u0026apos;s EEH nor PCI AER handling need. Tests show that PCI\nerror recovery on s390 is running to completion even without blocking\naccess to PCI config space.(CVE-2025-68310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Prevents free active kevent\n\nThe root cause of this issue are:\n1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);\nput the kevent work in global workqueue. However, the kevent has not yet\nbeen scheduled when the usbnet device is unregistered. Therefore, executing\nfree_netdev() results in the \u0026quot;free active object (kevent)\u0026quot; error reported\nhere.\n\n2. Another factor is that when calling usbnet_disconnect()-\u0026gt;unregister_netdev(),\nif the usbnet device is up, ndo_stop() is executed to cancel the kevent.\nHowever, because the device is not up, ndo_stop() is not executed.\n\nThe solution to this problem is to cancel the kevent before executing\nfree_netdev().(CVE-2025-68312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config unlock in nbd_genl_connect\n\nThere is one use-after-free warning when running NBD_CMD_CONNECT and\nNBD_CLEAR_SOCK:\n\nnbd_genl_connect\n nbd_alloc_and_init_config // config_refs=1\n nbd_start_device // config_refs=2\n set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3\n recv_work done // config_refs=2\n\t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1\n\t\t\t\t\t\tclose nbd // config_refs=0\n refcount_inc -\u0026gt; uaf\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290\n nbd_genl_connect+0x16d0/0x1ab0\n genl_family_rcv_msg_doit+0x1f3/0x310\n genl_rcv_msg+0x44a/0x790\n\nThe issue can be easily reproduced by adding a small delay before\nrefcount_inc(\u0026amp;nbd-\u0026gt;config_refs) in nbd_genl_connect():\n\n mutex_unlock(\u0026amp;nbd-\u0026gt;config_lock);\n if (!ret) {\n set_bit(NBD_RT_HAS_CONFIG_REF, \u0026amp;config-\u0026gt;runtime_flags);\n+ printk(\u0026quot;before sleep\\n\u0026quot;);\n+ mdelay(5 * 1000);\n+ printk(\u0026quot;after sleep\\n\u0026quot;);\n refcount_inc(\u0026amp;nbd-\u0026gt;config_refs);\n nbd_connect_reply(info, nbd-\u0026gt;index);\n }(CVE-2025-68366)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse\n\nThe following warning appears when running syzkaller, and this issue also\nexists in the mainline code.\n\n ------------[ cut here ]------------\n list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.\n WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130\n Modules linked in:\n CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__list_add_valid_or_report+0xf7/0x130\n RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282\n RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817\n RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001\n RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c\n R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100\n R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48\n FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 80000000\n Call Trace:\n \u0026lt;TASK\u0026gt;\n input_register_handler+0xb3/0x210\n mac_hid_start_emulation+0x1c5/0x290\n mac_hid_toggle_emumouse+0x20a/0x240\n proc_sys_call_handler+0x4c2/0x6e0\n new_sync_write+0x1b1/0x2d0\n vfs_write+0x709/0x950\n ksys_write+0x12a/0x250\n do_syscall_64+0x5a/0x110\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe WARNING occurs when two processes concurrently write to the mac-hid\nemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().\nBoth processes read old_val=0, then both try to register the input handler,\nleading to a double list_add of the same handler.\n\n CPU0 CPU1\n ------------------------- -------------------------\n vfs_write() //write 1 vfs_write() //write 1\n proc_sys_write() proc_sys_write()\n mac_hid_toggle_emumouse() mac_hid_toggle_emumouse()\n old_val = *valp // old_val=0\n old_val = *valp // old_val=0\n mutex_lock_killable()\n proc_dointvec() // *valp=1\n mac_hid_start_emulation()\n input_register_handler()\n mutex_unlock()\n mutex_lock_killable()\n proc_dointvec()\n mac_hid_start_emulation()\n input_register_handler() //Trigger Warning\n mutex_unlock()\n\nFix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: smartpqi: Fix device resources accessed after device removal\n\nCorrect possible race conditions during device removal.\n\nPreviously, a scheduled work item to reset a LUN could still execute\nafter the device was removed, leading to use-after-free and other\nresource access issues.\n\nThis race condition occurs because the abort handler may schedule a LUN\nreset concurrently with device removal via sdev_destroy(), leading to\nuse-after-free and improper access to freed resources.\n\n - Check in the device reset handler if the device is still present in\n the controller\u0026apos;s SCSI device list before running; if not, the reset\n is skipped.\n\n - Cancel any pending TMF work that has not started in sdev_destroy().\n\n - Ensure device freeing in sdev_destroy() is done while holding the\n LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config put in recv_work\n\nThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK and\nNBD_CMD_RECONFIGURE:\n nbd_genl_connect // conf_ref=2 (connect and recv_work A)\n nbd_open\t // conf_ref=3\n recv_work A done // conf_ref=2\n NBD_CLEAR_SOCK // conf_ref=1\n nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)\n close nbd\t // conf_ref=1\n recv_work B\n config_put // conf_ref=0\n atomic_dec(\u0026amp;config-\u0026gt;recv_threads); -\u0026gt; UAF\n\nOr only running NBD_CLEAR_SOCK:\n nbd_genl_connect // conf_ref=2\n nbd_open \t // conf_ref=3\n NBD_CLEAR_SOCK // conf_ref=2\n close nbd\n nbd_release\n config_put // conf_ref=1\n recv_work\n config_put \t // conf_ref=0\n atomic_dec(\u0026amp;config-\u0026gt;recv_threads); -\u0026gt; UAF\n\nCommit 87aac3a80af5 (\u0026quot;nbd: call nbd_config_put() before notifying the\nwaiter\u0026quot;) moved nbd_config_put() to run before waking up the waiter in\nrecv_work, in order to ensure that nbd_start_device_ioctl() would not\nbe woken up while nbd-\u0026gt;task_recv was still uncleared.\n\nHowever, in nbd_start_device_ioctl(), after being woken up it explicitly\ncalls flush_workqueue() to make sure all current works are finished.\nTherefore, there is no need to move the config put ahead of the wakeup.\n\nMove nbd_config_put() to the end of recv_work, so that the reference is\nheld for the whole lifetime of the worker thread. This makes sure the\nconfig cannot be freed while recv_work is still running, even if clear\n+ reconfigure interleave.\n\nIn addition, we don\u0026apos;t need to worry about recv_work dropping the last\nnbd_put (which causes deadlock):\n\npath A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):\n connect // nbd_refs=1 (trigger recv_work)\n open nbd // nbd_refs=2\n NBD_CLEAR_SOCK\n close nbd\n nbd_release\n nbd_disconnect_and_put\n flush_workqueue // recv_work done\n nbd_config_put\n nbd_put // nbd_refs=1\n nbd_put // nbd_refs=0\n queue_work\n\npath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):\n connect // nbd_refs=2 (trigger recv_work)\n open nbd // nbd_refs=3\n NBD_CLEAR_SOCK // conf_refs=2\n close nbd\n nbd_release\n nbd_config_put // conf_refs=1\n nbd_put // nbd_refs=2\n recv_work done // conf_refs=0, nbd_refs=1\n rmmod // nbd_refs=0\n\nDepends-on: e2daec488c57 (\u0026quot;nbd: Fix hungtask when nbd_config_put\u0026quot;)(CVE-2025-68372)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix rcu protection in md_wakeup_thread\n\nWe attempted to use RCU to protect the pointer \u0026apos;thread\u0026apos;, but directly\npassed the value when calling md_wakeup_thread(). This means that the\nRCU pointer has been acquired before rcu_read_lock(), which renders\nrcu_read_lock() ineffective and could lead to a use-after-free.(CVE-2025-68374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix null deref on srq-\u0026gt;rq.queue after resize failure\n\nA NULL pointer dereference can occur in rxe_srq_chk_attr() when\nibv_modify_srq() is invoked twice in succession under certain error\nconditions. The first call may fail in rxe_queue_resize(), which leads\nrxe_srq_from_attr() to set srq-\u0026gt;rq.queue = NULL. The second call then\ntriggers a crash (null deref) when accessing\nsrq-\u0026gt;rq.queue-\u0026gt;buf-\u0026gt;index_mask.\n\nCall Trace:\n\u0026lt;TASK\u0026gt;\nrxe_modify_srq+0x170/0x480 [rdma_rxe]\n? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]\n? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]\n? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]\nib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]\n? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]\n? tryinc_node_nr_active+0xe6/0x150\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\nib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]\n? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]\n? __pfx___raw_spin_lock_irqsave+0x10/0x10\n? __pfx_do_vfs_ioctl+0x10/0x10\n? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0\n? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10\nib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]\n? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]\n__x64_sys_ioctl+0x138/0x1c0\ndo_syscall_64+0x82/0x250\n? fdget_pos+0x58/0x4c0\n? ksys_write+0xf3/0x1c0\n? __pfx_ksys_write+0x10/0x10\n? do_syscall_64+0xc8/0x250\n? __pfx_vm_mmap_pgoff+0x10/0x10\n? fget+0x173/0x230\n? fput+0x2a/0x80\n? ksys_mmap_pgoff+0x224/0x4c0\n? do_syscall_64+0xc8/0x250\n? do_user_addr_fault+0x37b/0xfe0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-68379)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags\n\nWhen a filesystem is being automounted, it needs to preserve the\nuser-set superblock mount options, such as the \u0026quot;ro\u0026quot; flag.(CVE-2025-68764)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfsnotify: do not generate ACCESS/MODIFY events on child for special files\n\ninotify/fanotify do not allow users with no read access to a file to\nsubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the\nsame user to subscribe for watching events on children when the user\nhas access to the parent directory (e.g. /dev).\n\nUsers with no read access to a file but with read access to its parent\ndirectory can still stat the file and see if it was accessed/modified\nvia atime/mtime change.\n\nThe same is not true for special files (e.g. /dev/null). Users will not\ngenerally observe atime/mtime changes when other users read/write to\nspecial files, only when someone sets atime/mtime via utimensat().\n\nAlign fsnotify events with this stat behavior and do not generate\nACCESS/MODIFY events to parent watchers on read/write of special files.\nThe events are still generated to parent watchers on utimensat(). This\ncloses some side-channels that could be possibly used for information\nexfiltration [1].\n\n[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: missing copy_finish in fuse-over-io-uring argument copies\n\nFix a possible reference count leak of payload pages during\nfuse argument copies.\n\n[Joanne: simplified error cleanup](CVE-2025-68791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd: Check event before enable to avoid GPF\n\nOn AMD machines cpuc-\u0026gt;events[idx] can become NULL in a subtle race\ncondition with NMI-\u0026gt;throttle-\u0026gt;x86_pmu_stop().\n\nCheck event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.\nThis appears to be an AMD only issue.\n\nSyzkaller reported a GPF in amd_pmu_enable_all.\n\nINFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143\n msecs\nOops: general protection fault, probably for non-canonical address\n 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]\nCPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk\nRIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195\n arch/x86/events/core.c:1430)\nRSP: 0018:ffff888118009d60 EFLAGS: 00010012\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002\nR13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601\nFS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\namd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))\nx86_pmu_enable (arch/x86/events/core.c:1360)\nevent_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186\n kernel/events/core.c:2346)\n__perf_remove_from_context (kernel/events/core.c:2435)\nevent_function (kernel/events/core.c:259)\nremote_function (kernel/events/core.c:92 (discriminator 1)\n kernel/events/core.c:72 (discriminator 1))\n__flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27\n ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64\n kernel/smp.c:135 kernel/smp.c:540)\n__sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27\n ./include/linux/jump_label.h:207\n ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)\nsysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)\n arch/x86/kernel/smp.c:266 (discriminator 47))\n \u0026lt;/IRQ\u0026gt;(CVE-2025-68798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats\n\nCited commit added a dedicated mutex (instead of RTNL) to protect the\nmulticast route list, so that it will not change while the driver\nperiodically traverses it in order to update the kernel about multicast\nroute stats that were queried from the device.\n\nOne instance of list entry deletion (during route replace) was missed\nand it can result in a use-after-free [1].\n\nFix by acquiring the mutex before deleting the entry from the list and\nreleasing it afterwards.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]\nRead of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043\n\nCPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)\nHardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017\nWorkqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xba/0x110\n print_report+0x174/0x4f5\n kasan_report+0xdf/0x110\n mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 29933:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]\n mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30\n\nFreed by task 29933:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x70\n __kasan_slab_free+0x43/0x70\n kfree+0x14e/0x700\n mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]\n mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30(CVE-2025-68800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix neighbour use-after-free\n\nWe sometimes observe use-after-free when dereferencing a neighbour [1].\nThe problem seems to be that the driver stores a pointer to the\nneighbour, but without holding a reference on it. A reference is only\ntaken when the neighbour is used by a nexthop.\n\nFix by simplifying the reference counting scheme. Always take a\nreference when storing a neighbour pointer in a neighbour entry. Avoid\ntaking a referencing when the neighbour is used by a nexthop as the\nneighbour entry associated with the nexthop already holds a reference.\n\nTested by running the test that uncovered the problem over 300 times.\nWithout this patch the problem was reproduced after a handful of\niterations.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310\nRead of size 8 at addr ffff88817f8e3420 by task ip/3929\n\nCPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6e/0x300\n print_report+0xfc/0x1fb\n kasan_report+0xe4/0x110\n mlxsw_sp_neigh_entry_update+0x2d4/0x310\n mlxsw_sp_router_rif_gone_sync+0x35f/0x510\n mlxsw_sp_rif_destroy+0x1ea/0x730\n mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0\n __mlxsw_sp_inetaddr_lag_event+0xcc/0x130\n __mlxsw_sp_inetaddr_event+0xf5/0x3c0\n mlxsw_sp_router_netdevice_event+0x1015/0x1580\n notifier_call_chain+0xcc/0x150\n call_netdevice_notifiers_info+0x7e/0x100\n __netdev_upper_dev_unlink+0x10b/0x210\n netdev_upper_dev_unlink+0x79/0xa0\n vrf_del_slave+0x18/0x50\n do_set_master+0x146/0x7d0\n do_setlink.isra.0+0x9a0/0x2880\n rtnl_newlink+0x637/0xb20\n rtnetlink_rcv_msg+0x6fe/0xb90\n netlink_rcv_skb+0x123/0x380\n netlink_unicast+0x4a3/0x770\n netlink_sendmsg+0x75b/0xc90\n __sock_sendmsg+0xbe/0x160\n ____sys_sendmsg+0x5b2/0x7d0\n ___sys_sendmsg+0xfd/0x180\n __sys_sendmsg+0x124/0x1c0\n do_syscall_64+0xbb/0xfd0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[...]\n\nAllocated by task 109:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x2c1/0x790\n neigh_alloc+0x6af/0x8f0\n ___neigh_create+0x63/0xe90\n mlxsw_sp_nexthop_neigh_init+0x430/0x7e0\n mlxsw_sp_nexthop_type_init+0x212/0x960\n mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280\n mlxsw_sp_nexthop6_group_get+0x392/0x6a0\n mlxsw_sp_fib6_entry_create+0x46a/0xfd0\n mlxsw_sp_router_fib6_replace+0x1ed/0x5f0\n mlxsw_sp_router_fib6_event_work+0x10a/0x2a0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nFreed by task 154:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x43/0x70\n kmem_cache_free_bulk.part.0+0x1eb/0x5e0\n kvfree_rcu_bulk+0x1f2/0x260\n kfree_rcu_work+0x130/0x1b0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nLast potentially related work creation:\n kasan_save_stack+0x30/0x50\n kasan_record_aux_stack+0x8c/0xa0\n kvfree_call_rcu+0x93/0x5b0\n mlxsw_sp_router_neigh_event_work+0x67d/0x860\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20(CVE-2025-68801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix io-uring list corruption for terminated non-committed requests\n\nWhen a request is terminated before it has been committed, the request\nis not removed from the queue\u0026apos;s list. This leaves a dangling list entry\nthat leads to list corruption and use-after-free issues.\n\nRemove the request from the queue\u0026apos;s list for terminated non-committed\nrequests.(CVE-2025-68805)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix readahead reclaim deadlock\n\nCommit e26ee4efbc79 (\u0026quot;fuse: allocate ff-\u0026gt;release_args only if release is\nneeded\u0026quot;) skips allocating ff-\u0026gt;release_args if the server does not\nimplement open. However in doing so, fuse_prepare_release() now skips\ngrabbing the reference on the inode, which makes it possible for an\ninode to be evicted from the dcache while there are inflight readahead\nrequests. This causes a deadlock if the server triggers reclaim while\nservicing the readahead request and reclaim attempts to evict the inode\nof the file being read ahead. Since the folio is locked during\nreadahead, when reclaim evicts the fuse inode and fuse_evict_inode()\nattempts to remove all folios associated with the inode from the page\ncache (truncate_inode_pages_range()), reclaim will block forever waiting\nfor the lock since readahead cannot relinquish the lock because it is\nitself blocked in reclaim:\n\n\u0026gt;\u0026gt;\u0026gt; stack_trace(1504735)\n folio_wait_bit_common (mm/filemap.c:1308:4)\n folio_lock (./include/linux/pagemap.h:1052:3)\n truncate_inode_pages_range (mm/truncate.c:336:10)\n fuse_evict_inode (fs/fuse/inode.c:161:2)\n evict (fs/inode.c:704:3)\n dentry_unlink_inode (fs/dcache.c:412:3)\n __dentry_kill (fs/dcache.c:615:3)\n shrink_kill (fs/dcache.c:1060:12)\n shrink_dentry_list (fs/dcache.c:1087:3)\n prune_dcache_sb (fs/dcache.c:1168:2)\n super_cache_scan (fs/super.c:221:10)\n do_shrink_slab (mm/shrinker.c:435:9)\n shrink_slab (mm/shrinker.c:626:10)\n shrink_node (mm/vmscan.c:5951:2)\n shrink_zones (mm/vmscan.c:6195:3)\n do_try_to_free_pages (mm/vmscan.c:6257:3)\n do_swap_page (mm/memory.c:4136:11)\n handle_pte_fault (mm/memory.c:5562:10)\n handle_mm_fault (mm/memory.c:5870:9)\n do_user_addr_fault (arch/x86/mm/fault.c:1338:10)\n handle_page_fault (arch/x86/mm/fault.c:1481:3)\n exc_page_fault (arch/x86/mm/fault.c:1539:2)\n asm_exc_page_fault+0x22/0x27\n\nFix this deadlock by allocating ff-\u0026gt;release_args and grabbing the\nreference on the inode when preparing the file for release even if the\nserver does not implement open. The inode reference will be dropped when\nthe last reference on the fuse file is dropped (see fuse_file_put() -\u0026gt;\nfuse_release_end()).(CVE-2025-68821)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\u0026quot;i40evf: Allow PF driver to configure RSS\u0026quot;),\nthe loop upper bounds were:\n i \u0026lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u0026lt;= adapter-\u0026gt;rss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u0026lt;=`\naccesses one element past the end.\n\nFix the issues by using `\u0026lt;` instead of `\u0026lt;=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u0026gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000: fix OOB in e1000_tbi_should_accept()\n\nIn e1000_tbi_should_accept() we read the last byte of the frame via\n\u0026apos;data[length - 1]\u0026apos; to evaluate the TBI workaround. If the descriptor-\nreported length is zero or larger than the actual RX buffer size, this\nread goes out of bounds and can hit unrelated slab objects. The issue\nis observed from the NAPI receive path (e1000_clean_rx_irq):\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790\nRead of size 1 at addr ffff888014114e54 by task sshd/363\n\nCPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x5a/0x74\n print_address_description+0x7b/0x440\n print_report+0x101/0x200\n kasan_report+0xc1/0xf0\n e1000_tbi_should_accept+0x610/0x790\n e1000_clean_rx_irq+0xa8c/0x1110\n e1000_clean+0xde2/0x3c10\n __napi_poll+0x98/0x380\n net_rx_action+0x491/0xa20\n __do_softirq+0x2c9/0x61d\n do_softirq+0xd1/0x120\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0xfe/0x130\n ip_finish_output2+0x7d5/0xb00\n __ip_queue_xmit+0xe24/0x1ab0\n __tcp_transmit_skb+0x1bcb/0x3340\n tcp_write_xmit+0x175d/0x6bd0\n __tcp_push_pending_frames+0x7b/0x280\n tcp_sendmsg_locked+0x2e4f/0x32d0\n tcp_sendmsg+0x24/0x40\n sock_write_iter+0x322/0x430\n vfs_write+0x56c/0xa60\n ksys_write+0xd1/0x190\n do_syscall_64+0x43/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f511b476b10\nCode: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24\nRSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10\nRDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003\nRBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00\nR10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003\n \u0026lt;/TASK\u0026gt;\nAllocated by task 1:\n __kasan_krealloc+0x131/0x1c0\n krealloc+0x90/0xc0\n add_sysfs_param+0xcb/0x8a0\n kernel_add_sysfs_param+0x81/0xd4\n param_sysfs_builtin+0x138/0x1a6\n param_sysfs_init+0x57/0x5b\n do_one_initcall+0x104/0x250\n do_initcall_level+0x102/0x132\n do_initcalls+0x46/0x74\n kernel_init_freeable+0x28f/0x393\n kernel_init+0x14/0x1a0\n ret_from_fork+0x22/0x30\nThe buggy address belongs to the object at ffff888014114000\n which belongs to the cache kmalloc-2k of size 2048\nThe buggy address is located 1620 bytes to the right of\n 2048-byte region [ffff888014114000, ffff888014114800]\nThe buggy address belongs to the physical page:\npage:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110\nhead:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0\nflags: 0x100000000010200(slab|head|node=0|zone=1)\nraw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000\nraw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n==================================================================\n\nThis happens because the TBI check unconditionally dereferences the last\nbyte without validating the reported length first:\n\n\tu8 last_byte = *(data + length - 1);\n\nFix by rejecting the frame early if the length is zero, or if it exceeds\nadapter-\u0026gt;rx_buffer_len. This preserves the TBI workaround semantics for\nvalid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: Handle incorrect num_connectors capability\n\nThe UCSI spec states that the num_connectors field is 7 bits, and the\n8th bit is reserved and should be set to zero.\nSome buggy FW has been known to set this bit, and it can lead to a\nsystem not booting.\nFlag that the FW is not behaving correctly, and auto-fix the value\nso that the system boots correctly.\n\nFound on Lenovo P1 G8 during Linux enablement program. The FW will\nbe fixed, but seemed worth addressing in case it hit platforms that\naren\u0026apos;t officially Linux supported.(CVE-2025-71108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - zero initialize memory allocated via sock_kmalloc\n\nSeveral crypto user API contexts and requests allocated with\nsock_kmalloc() were left uninitialized, relying on callers to\nset fields explicitly. This resulted in the use of uninitialized\ndata in certain error paths or when new fields are added in the\nfuture.\n\nThe ACVP patches also contain two user-space interface files:\nalgif_kpp.c and algif_akcipher.c. These too rely on proper\ninitialization of their context structures.\n\nA particular issue has been observed with the newly added\n\u0026apos;inflight\u0026apos; variable introduced in af_alg_ctx by commit:\n\n 67b164a871af (\u0026quot;crypto: af_alg - Disallow multiple in-flight AIO requests\u0026quot;)\n\nBecause the context is not memset to zero after allocation,\nthe inflight variable has contained garbage values. As a result,\naf_alg_alloc_areq() has incorrectly returned -EBUSY randomly when\nthe garbage value was interpreted as true:\n\n https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209\n\nThe check directly tests ctx-\u0026gt;inflight without explicitly\ncomparing against true/false. Since inflight is only ever set to\ntrue or false later, an uninitialized value has triggered\n-EBUSY failures. Zero-initializing memory allocated with\nsock_kmalloc() ensures inflight and other fields start in a known\nstate, removing random issues caused by uninitialized data.(CVE-2025-71113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/kexec: Enable SMT before waking offline CPUs\n\nIf SMT is disabled or a partial SMT state is enabled, when a new kernel\nimage is loaded for kexec, on reboot the following warning is observed:\n\nkexec: Waking offline cpu 228.\nWARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc\n[snip]\n NIP kexec_prepare_cpus+0x1b0/0x1bc\n LR kexec_prepare_cpus+0x1a0/0x1bc\n Call Trace:\n kexec_prepare_cpus+0x1a0/0x1bc (unreliable)\n default_machine_kexec+0x160/0x19c\n machine_kexec+0x80/0x88\n kernel_kexec+0xd0/0x118\n __do_sys_reboot+0x210/0x2c4\n system_call_exception+0x124/0x320\n system_call_vectored_common+0x15c/0x2ec\n\nThis occurs as add_cpu() fails due to cpu_bootable() returning false for\nCPUs that fail the cpu_smt_thread_allowed() check or non primary\nthreads if SMT is disabled.\n\nFix the issue by enabling SMT and resetting the number of SMT threads to\nthe number of threads per core, before attempting to wake up all present\nCPUs.(CVE-2025-71119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not register unsupported perf events\n\nSynthetic events currently do not have a function to register perf events.\nThis leads to calling the tracepoint register functions with a NULL\nfunction pointer which triggers:\n\n ------------[ cut here ]------------\n WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:tracepoint_add_func+0x357/0x370\n Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc \u0026lt;0f\u0026gt; 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f\n RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246\n RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000\n RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8\n RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780\n R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a\n R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78\n FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register+0x5d/0x90\n synth_event_reg+0x3c/0x60\n perf_trace_event_init+0x204/0x340\n perf_trace_init+0x85/0xd0\n perf_tp_event_init+0x2e/0x50\n perf_try_init_event+0x6f/0x230\n ? perf_event_alloc+0x4bb/0xdc0\n perf_event_alloc+0x65a/0xdc0\n __se_sys_perf_event_open+0x290/0x9f0\n do_syscall_64+0x93/0x7b0\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? trace_hardirqs_off+0x53/0xc0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInstead, have the code return -ENODEV, which doesn\u0026apos;t warn and has perf\nerror out with:\n\n # perf record -e synthetic:futex_wait\nError:\nThe sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).\n\u0026quot;dmesg | grep -i perf\u0026quot; may provide additional information.\n\nIdeally perf should support synthetic events, but for now just fix the\nwarning. The support can come later.(CVE-2025-71125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix memory and information leak in smb3_reconfigure()\n\nIn smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the\nfunction returns immediately without freeing and erasing the newly\nallocated new_password and new_password2. This causes both a memory leak\nand a potential information leak.\n\nFix this by calling kfree_sensitive() on both password buffers before\nreturning in this error case.(CVE-2025-71151)",
"id": "OESA-2026-1303",
"modified": "2026-08-06T11:10:20Z",
"published": "2026-02-06T11:10:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1303"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38110"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38162"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38208"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38303"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38712"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39721"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40252"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40264"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40268"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40311"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40314"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40328"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40345"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40360"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40363"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68185"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68191"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68218"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68219"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68251"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68295"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68296"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68367"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68371"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68372"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68374"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68379"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68764"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68788"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71113"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71151"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-57994",
"CVE-2024-58012",
"CVE-2025-37800",
"CVE-2025-38110",
"CVE-2025-38111",
"CVE-2025-38149",
"CVE-2025-38162",
"CVE-2025-38208",
"CVE-2025-38232",
"CVE-2025-38244",
"CVE-2025-38303",
"CVE-2025-38342",
"CVE-2025-38393",
"CVE-2025-38455",
"CVE-2025-38489",
"CVE-2025-38676",
"CVE-2025-38688",
"CVE-2025-38697",
"CVE-2025-38712",
"CVE-2025-38713",
"CVE-2025-38714",
"CVE-2025-38728",
"CVE-2025-39720",
"CVE-2025-39721",
"CVE-2025-39730",
"CVE-2025-39737",
"CVE-2025-39749",
"CVE-2025-39798",
"CVE-2025-39823",
"CVE-2025-39828",
"CVE-2025-39838",
"CVE-2025-39839",
"CVE-2025-39927",
"CVE-2025-39929",
"CVE-2025-39951",
"CVE-2025-40083",
"CVE-2025-40087",
"CVE-2025-40099",
"CVE-2025-40103",
"CVE-2025-40105",
"CVE-2025-40111",
"CVE-2025-40250",
"CVE-2025-40252",
"CVE-2025-40259",
"CVE-2025-40261",
"CVE-2025-40264",
"CVE-2025-40268",
"CVE-2025-40273",
"CVE-2025-40284",
"CVE-2025-40304",
"CVE-2025-40311",
"CVE-2025-40314",
"CVE-2025-40319",
"CVE-2025-40320",
"CVE-2025-40322",
"CVE-2025-40324",
"CVE-2025-40328",
"CVE-2025-40345",
"CVE-2025-40350",
"CVE-2025-40360",
"CVE-2025-40363",
"CVE-2025-68178",
"CVE-2025-68184",
"CVE-2025-68185",
"CVE-2025-68191",
"CVE-2025-68218",
"CVE-2025-68219",
"CVE-2025-68229",
"CVE-2025-68239",
"CVE-2025-68241",
"CVE-2025-68245",
"CVE-2025-68251",
"CVE-2025-68288",
"CVE-2025-68295",
"CVE-2025-68296",
"CVE-2025-68305",
"CVE-2025-68310",
"CVE-2025-68312",
"CVE-2025-68366",
"CVE-2025-68367",
"CVE-2025-68371",
"CVE-2025-68372",
"CVE-2025-68374",
"CVE-2025-68379",
"CVE-2025-68764",
"CVE-2025-68788",
"CVE-2025-68791",
"CVE-2025-68798",
"CVE-2025-68800",
"CVE-2025-68801",
"CVE-2025-68805",
"CVE-2025-68821",
"CVE-2025-71087",
"CVE-2025-71093",
"CVE-2025-71108",
"CVE-2025-71113",
"CVE-2025-71119",
"CVE-2025-71125",
"CVE-2025-71151"
]
}
OESA-2026-1304 (CVE-2024-57994)
Vulnerability from osv_openeuler – Published: 2026-02-06 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()
Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.
syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]
As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.
Rename helpers to better reflect they are safe against BH only.
- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
- skb_array_resize_multiple() to skb_array_resize_multiple_bh()
[1]
WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tun_ptr_free drivers/net/tun.c:617 [inline] __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline] ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline] tun_queue_resize drivers/net/tun.c:3694 [inline] tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550(CVE-2024-57994)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params
Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.(CVE-2024-58012)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential NULL pointer dereference in dev_uevent()
If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it.
Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing.(CVE-2025-37800)
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds clause 45 read/write access
When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.
Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38110)
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds read/write access
When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.
Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38111)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: clear phydev->devlink when the link is deleted
There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows.
[ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34
Therefore, phydev->devlink needs to be cleared when the device link is deleted.(CVE-2025-38149)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: prevent overflow in lookup table allocation
When calculating the lookup table size, ensure the following multiplication does not overflow:
- desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.
- NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.
- sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field.
Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this.
While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().(CVE-2025-38162)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: add NULL check in automount_fullpath
page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: fix race between nfsd registration and exports_proc
As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd.
Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd
for 5.4 kernel ARM64:
CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0
CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
PC is at : exports_net_open+0x50/0x68 [nfsd]
Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248
Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().
and same is happening on latest 6.14 kernel as well:
[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]---
It reproduced simply with below script: while [ 1 ] do /exportfs -r done &
while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done &
So exporting interfaces to user space shall be done at last and cleanup at first place.
With change there is no Kernel OOPs.(CVE-2025-38232)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential deadlock when reconnecting channels
Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening
====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W
cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200
but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30
other info that might help us debug this:
Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock);
*** DEADLOCK ***
3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200(CVE-2025-38244)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: eir: Fix possible crashes on eir_create_adv_data
eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.(CVE-2025-38303)
In the Linux kernel, the following vulnerability has been resolved:
software node: Correct a OOB check in software_node_get_reference_args()
software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property.
Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN
We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero.
It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.(CVE-2025-38393)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight
Reject migration of SEV{-ES} state if either the source or destination VM is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the section between incrementing created_vcpus and online_vcpus. The bulk of vCPU creation runs outside of kvm->lock to allow creating multiple vCPUs in parallel, and so sev_info.es_active can get toggled from false=>true in the destination VM after (or during) svm_vcpu_create(), resulting in an SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.
The issue manifests most visibly as a crash when trying to free a vCPU's NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.
BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:freepages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 </TASK> Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]---
Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated---(CVE-2025-38455)
In the Linux kernel, the following vulnerability has been resolved:
s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again
Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear.
Restore the fix and add a comment.(CVE-2025-38489)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Avoid stack buffer overflow from kernel cmdline
While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Prevent ALIGN() overflow
When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova.
Open code the ALIGN() using get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either.
Consolidate the two copies of this code under a single helper.
This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range.(CVE-2025-38688)
In the Linux kernel, the following vulnerability has been resolved:
jfs: upper bound check of tree index in dbAllocAG
When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.(CVE-2025-38697)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplus_fill_super() assumes that the attributes file is not yet created, which later results in hitting BUG_ON() when hfsplus_create_attributes_file() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc():
[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfxx64sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---(CVE-2025-38713)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
The hfsplus_bnode_read() method can trigger the issue:
[ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] <TASK> [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0 [ 174.854305][ T9784] print_report+0xd0/0x660 [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610 [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854337][ T9784] kasan_report+0xc6/0x100 [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360 [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380 [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10 [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0 [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310 [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0 [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0 [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10 [ 174.854427][ T9784] ? __pfxhfsplusdelete_attr+0x10/0x10 [ 174.854436][ T9784] ? asan_memset+0x23/0x50 [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320 [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10 [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0 [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0 [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10 [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10 [ 174.854525][ T9784] ? down_write+0x148/0x200 [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10 [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0 [ 174.854549][ T9784] do_unlinkat+0x490/0x670 [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10 [ 174.854565][ T9784] ? __might_fault+0xbc/0x130 [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550 [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110 [ 174.854592][ T9784] do_syscall_64+0xc9/0x480 [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] </TASK> [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasan_save_stack+0x20/0x40 [ 174.880082][ T9784] kasan_save_track+0x14/0x30 [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0 [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550 [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890 [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10 [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520 [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3 ---truncated---(CVE-2025-38714)
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix for slab out of bounds on mount to ksmbd
With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below):
BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827
CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 cifs
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix refcount leak causing resource not released
When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.(CVE-2025-39720)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - flush misc workqueue during device shutdown
Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded.
Since the driver uses a shared workqueue (qat_misc_wq) across all
devices and owned by intel_qat.ko, a deferred routine from the
device-specific driver may still be pending in the queue. If this
routine executes after the driver is unloaded, it can dereference freed
memory, resulting in a page fault and kernel crash like the following:
BUG: unable to handle page fault for address: ffa000002e50a01c
#PF: supervisor read access in kernel mode
RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
Call Trace:
pm_bh_handler+0x1d2/0x250 [intel_qat]
process_one_work+0x171/0x340
worker_thread+0x277/0x3a0
kthread+0xf0/0x120
ret_from_fork+0x2d/0x50
To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.
Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.(CVE-2025-39721)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()
The function needs to check the minimal filehandle length before it can access the embedded filehandle.(CVE-2025-39730)
In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()
A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.
watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]
The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.
The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects.
As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.(CVE-2025-39737)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Protect ->defer_qs_iw_pending from data race
On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.
In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.
The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat:
BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special
read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0
The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.
This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix the setting of capabilities when automounting a new filesystem
Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again.(CVE-2025-39798)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: use array_index_nospec with indices that come from guest
min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.(CVE-2025-39823)
In the Linux kernel, the following vulnerability has been resolved:
atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().
syzbot reported the splat below. [0]
When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.
The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.
The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.
struct atmtcp_control { struct atmtcp_hdr hdr; / must be first / ... atm_kptr_t vcc; / both directions / ... } __ATM_API_ALIGN;
typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;
The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().
atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:
- .ndo_start_xmit() (vcc->send() == atm_send_aal0())
- vcc_sendmsg()
The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.
Let's add a new ->pre_send() hook to validate messages from sendmsg().
[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 _syssendmsg+0x505/0x830 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in:(CVE-2025-39828)
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent NULL pointer dereference in UTF16 conversion
There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.
This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer.
Found by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix OOB read/write in network-coding decode
batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.
Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.(CVE-2025-39839)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix race condition validating r_parent before applying state
Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes.
[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated:
When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ](CVE-2025-39927)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path
During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()(CVE-2025-39929)
In the Linux kernel, the following vulnerability has been resolved:
um: virtio_uml: Fix use-after-free after put_device in probe
When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.(CVE-2025-39951)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix null-deref in agg_dequeue
To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c.
To avoid code duplication, the following changes are made:
-
Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function.
-
Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it.
-
Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Define a proc_layoutcommit for the FlexFiles layout type
Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.(CVE-2025-40087)
In the Linux kernel, the following vulnerability has been resolved:
cifs: parse_dfs_referrals: prevent oob on malformed input
Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS
- reply smaller than sizeof(struct get_dfs_referral_rsp)
- reply with number of referrals smaller than NumberOfReferrals in the header
Processing of such replies will cause oob.
Return -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix refcount leak for cifs_sb_tlink
Fix three refcount inconsistency issues related to cifs_sb_tlink.
Comments for cifs_sb_tlink state that cifs_put_tlink() needs to be
called after successful calls to cifs_sb_tlink(). Three calls fail to
update refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't leak disconnected dentries on umount
When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix Use-after-free in validation
Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.(CVE-2025-40111)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Clean up only new IRQ glue on request_irq() failure
The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added.
This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object.
Note: This error is observed when both fwctl and rds configs are enabled.
[1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI
RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: <TASK> ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a _syssendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b _sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---(CVE-2025-40250)
In the Linux kernel, the following vulnerability has been resolved:
net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()
The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array.
Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40252)
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Do not sleep in atomic context
sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.(CVE-2025-40259)
In the Linux kernel, the following vulnerability has been resolved:
nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()
nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur:
[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] </TASK>(CVE-2025-40261)
In the Linux kernel, the following vulnerability has been resolved:
be2net: pass wrb_params in case of OS2BMC
be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states.
The correct way would be to pass the wrb_params from be_xmit().(CVE-2025-40264)
In the Linux kernel, the following vulnerability has been resolved:
cifs: client: fix memory leak in smb3_fs_context_parse_param
The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation.
To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing.
syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444
BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: free copynotify stateid in nfs4_free_ol_stateid()
Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period.
However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred
WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]
This patch, instead, frees the associated copynotify stateid here.
If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later.
[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: cancel mesh send timer when hdev removed
mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone.
Cancel the timer when MGMT removes the hdev, like other MGMT timers.
Should fix the BUG: sporadically seen by BlueZ test bot (in "Mesh - Send cancel - 1" test).
Log:
BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------(CVE-2025-40284)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches.
Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)
In the Linux kernel, the following vulnerability has been resolved:
accel/habanalabs: support mapping cb with vmalloc-backed coherent memory
When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction.
Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.(CVE-2025-40311)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget
In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free.
Fix: By separating the usb_del_gadget_udc() operation into distinct "del" and "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget().
A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").(CVE-2025-40314)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Sync pending IRQ work before freeing ring buffer
Fix a race where irq_work can be queued in bpf_ringbuf_commit()
but the ring buffer is freed before the work executes.
In the syzbot reproducer, a BPF program attached to sched_switch
triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer
is freed before this work executes, the irq_work thread may accesses
freed memory.
Calling irq_work_sync(&rb->work) ensures that all pending irq_work
complete before freeing the buffer.(CVE-2025-40319)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential cfid UAF in smb2_query_info_compound
When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free.
Reinitialize cfid to NULL under the replay label.
Example trace (trimmed):
refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: <TASK> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80(CVE-2025-40320)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: bitblit: bound-check glyph index in bit_putcs*
bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address.
This fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix crash in nfsd4_read_release()
When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.(CVE-2025-40324)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_close_cached_fid()
find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free.
Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.(CVE-2025-40328)
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: sddr55: Reject out-of-bound new_pba
Discovered by Atuin - Automated Vulnerability Discovery Engine.
new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory.
Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ
XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run.
Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it.
To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.(CVE-2025-40350)
In the Linux kernel, the following vulnerability has been resolved:
drm/sysfb: Do not dereference NULL pointer in plane reset
The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL.
v2: - fix typo in commit description (Javier)(CVE-2025-40360)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix field-spanning memcpy warning in AH output
Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields.
memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439
The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.(CVE-2025-40363)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix possible deadlock while configuring policy
Following deadlock can be triggered easily by lockdep:
WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted
check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180
but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30
-> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
other info that might help us debug this:
Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock);
Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context.
The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.(CVE-2025-68178)
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Disable AFBC support on Mediatek DRM driver
Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier.
However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0.
Kernel trace reports vblank timeouts constantly, and the render is garbled:
[CRTC:62:crtc-0] vblank wait timed out
WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
[...]
Hardware name: MediaTek Genio-700 EVK (DT)
Workqueue: events_unbound commit_work
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
sp : ffff80008337bca0
x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000
x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000
x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80
x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a
x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000
x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b
x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70
x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70
x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480
Call trace:
drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)
drm_atomic_helper_commit_tail_rpm+0x64/0x80
commit_tail+0xa4/0x1a4
commit_work+0x14/0x20
process_one_work+0x150/0x290
worker_thread+0x2d0/0x3ec
kthread+0x12c/0x210
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.(CVE-2025-68184)
In the Linux kernel, the following vulnerability has been resolved:
nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack.
Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.(CVE-2025-68185)
In the Linux kernel, the following vulnerability has been resolved:
udp_tunnel: use netdev_warn() instead of netdev_WARN()
netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug.
udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug.
Replace netdev_WARN() with netdev_warn() accordingly.(CVE-2025-68191)
In the Linux kernel, the following vulnerability has been resolved:
nvme-multipath: fix lockdep WARN due to partition scan work
Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion.
To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.(CVE-2025-68218)
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix memory leak in smb3_fs_context_parse_param error path
Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues.
This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed.
The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak.
This issue was not addressed by commit e8c73eb7db0a ("cifs: client: fix memory leak in smb3_fs_context_parse_param"), which only fixed leaks from repeated fsconfig() calls but not this error path.
Patch updated with minor change suggested by kernel test robot(CVE-2025-68219)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.
Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...(CVE-2025-68229)
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: restore write access before closing files opened by open_exec()
bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed.
However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail.
Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.(CVE-2025-68239)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random.
The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked.
CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]
This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device:
unregister_netdevice: waiting for sitX to become free. Usage count = N
Ido Schimmel provided the simple test validation method [1].
The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed.
[1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1(CVE-2025-68241)
In the Linux kernel, the following vulnerability has been resolved:
net: netpoll: fix incorrect refcount handling causing incorrect cleanup
commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks.
Scenario causing lack of proper cleanup:
1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.
2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.
3) When the first netpolls goes to clean up:
- The first cleanup succeeds and clears np->dev->npinfo, ignoring
refcnt.
- It basically calls RCU_INIT_POINTER(np->dev->npinfo, NULL);
- Set dev->npinfo = NULL, without proper cleanup
- No ->ndo_netpoll_cleanup() is either called
4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.
Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.(CVE-2025-68245)
In the Linux kernel, the following vulnerability has been resolved:
erofs: avoid infinite loops due to corrupted subpage compact indexes
Robert reported an infinite loop observed by two crafted images.
The root cause is that clusterofs can be larger than lclustersize
for !NONHEAD lclusters in corrupted subpage compact indexes, e.g.:
blocksize = lclustersize = 512 lcn = 6 clusterofs = 515
Move the corresponding check for full compress indexes to
z_erofs_load_lcluster_from_disk() to also cover subpage compact
compress indexes.
It also fixes the position of m->type >= Z_EROFS_LCLUSTER_TYPE_MAX
check, since it should be placed right after
z_erofs_load_{compact,full}_lcluster().(CVE-2025-68251)
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase.
Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.(CVE-2025-68288)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix memory leak in cifs_construct_tcon()
When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon().
This fixes the following memory leak reported by kmemleak:
mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-68295)
In the Linux kernel, the following vulnerability has been resolved:
drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup
Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs.
VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array.
Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly.
Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all().
Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.(CVE-2025-68296)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sock: Prevent race in socket write iter and sock bind
There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1].
Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1].
[1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195
Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195
Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)
In the Linux kernel, the following vulnerability has been resolved:
s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump
Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do.
During error recovery testing a pair of tasks was reported to be hung:
mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]
No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too:
- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()
- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.
A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/<BDF> reporter fw_fatal
while PCI error recovery is executed on the same <BDF> physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw <BDF>
Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with "kernel answers: Permission denied" - and we get a kernel log message of:
mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5
because the config read of VSC_SEMAPHORE is rejected by the underlying hardware.
Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.(CVE-2025-68310)
In the Linux kernel, the following vulnerability has been resolved:
usbnet: Prevents free active kevent
The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here.
- Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed.
The solution to this problem is to cancel the kevent before executing free_netdev().(CVE-2025-68312)
In the Linux kernel, the following vulnerability has been resolved:
nbd: defer config unlock in nbd_genl_connect
There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK:
nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf
------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790
The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect():
mutex_unlock(&nbd->config_lock);
if (!ret) {
set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);
- printk("before sleep\n");
- mdelay(5 * 1000);
- printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }(CVE-2025-68366)
In the Linux kernel, the following vulnerability has been resolved:
macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse
The following warning appears when running syzkaller, and this issue also exists in the mainline code.
------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2
The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler.
CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = valp // old_val=0 old_val = valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()
Fix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)
In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Fix device resources accessed after device removal
Correct possible race conditions during device removal.
Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.
This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources.
-
Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.
-
Cancel any pending TMF work that has not started in sdev_destroy().
-
Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)
In the Linux kernel, the following vulnerability has been resolved:
nbd: defer config put in recv_work
There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF
Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF
Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the waiter") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared.
However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup.
Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave.
In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock):
path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work
path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0
Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")(CVE-2025-68372)
In the Linux kernel, the following vulnerability has been resolved:
md: fix rcu protection in md_wakeup_thread
We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.(CVE-2025-68374)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix null deref on srq->rq.queue after resize failure
A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask.
Call Trace: <TASK> rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfxrawspin_lock_irqsave+0x10/0x10 ? pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-68379)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags
When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.(CVE-2025-68764)
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: do not generate ACCESS/MODIFY events on child for special files
inotify/fanotify do not allow users with no read access to a file to subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the same user to subscribe for watching events on children when the user has access to the parent directory (e.g. /dev).
Users with no read access to a file but with read access to its parent directory can still stat the file and see if it was accessed/modified via atime/mtime change.
The same is not true for special files (e.g. /dev/null). Users will not generally observe atime/mtime changes when other users read/write to special files, only when someone sets atime/mtime via utimensat().
Align fsnotify events with this stat behavior and do not generate ACCESS/MODIFY events to parent watchers on read/write of special files. The events are still generated to parent watchers on utimensat(). This closes some side-channels that could be possibly used for information exfiltration [1].
[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)
In the Linux kernel, the following vulnerability has been resolved:
fuse: missing copy_finish in fuse-over-io-uring argument copies
Fix a possible reference count leak of payload pages during fuse argument copies.
Joanne: simplified error cleanup
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd: Check event before enable to avoid GPF
On AMD machines cpuc->events[idx] can become NULL in a subtle race condition with NMI->throttle->x86_pmu_stop().
Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF. This appears to be an AMD only issue.
Syzkaller reported a GPF in amd_pmu_enable_all.
INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143 msecs Oops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7] CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430) RSP: 0018:ffff888118009d60 EFLAGS: 00010012 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601 FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0 Call Trace: <IRQ> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2)) x86_pmu_enable (arch/x86/events/core.c:1360) event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346) __perf_remove_from_context (kernel/events/core.c:2435) event_function (kernel/events/core.c:259) remote_function (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1)) __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540) __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272) sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47)) </IRQ>(CVE-2025-68798)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats
Cited commit added a dedicated mutex (instead of RTNL) to protect the multicast route list, so that it will not change while the driver periodically traverses it in order to update the kernel about multicast route stats that were queried from the device.
One instance of list entry deletion (during route replace) was missed and it can result in a use-after-free [1].
Fix by acquiring the mutex before deleting the entry from the list and releasing it afterwards.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043
CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum] Call Trace: <TASK> dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30
Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30(CVE-2025-68800)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix neighbour use-after-free
We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.
Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.
Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929
CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 _syssendmsg+0x5b2/0x7d0 _sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [...]
Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20(CVE-2025-68801)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix io-uring list corruption for terminated non-committed requests
When a request is terminated before it has been committed, the request is not removed from the queue's list. This leaves a dangling list entry that leads to list corruption and use-after-free issues.
Remove the request from the queue's list for terminated non-committed requests.(CVE-2025-68805)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix readahead reclaim deadlock
Commit e26ee4efbc79 ("fuse: allocate ff->release_args only if release is needed") skips allocating ff->release_args if the server does not implement open. However in doing so, fuse_prepare_release() now skips grabbing the reference on the inode, which makes it possible for an inode to be evicted from the dcache while there are inflight readahead requests. This causes a deadlock if the server triggers reclaim while servicing the readahead request and reclaim attempts to evict the inode of the file being read ahead. Since the folio is locked during readahead, when reclaim evicts the fuse inode and fuse_evict_inode() attempts to remove all folios associated with the inode from the page cache (truncate_inode_pages_range()), reclaim will block forever waiting for the lock since readahead cannot relinquish the lock because it is itself blocked in reclaim:
>>> stack_trace(1504735) folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate.c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache.c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c:221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195:3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/x86/mm/fault.c:1481:3) exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27
Fix this deadlock by allocating ff->release_args and grabbing the reference on the inode when preparing the file for release even if the server does not implement open. The inode reference will be dropped when the last reference on the fuse file is dropped (see fuse_file_put() -> fuse_release_end()).(CVE-2025-68821)
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix off-by-one issues in iavf_config_rss_reg()
There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX which is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4
where rss_{key,lut}_size / 4 is the number of dwords, so the last
valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <=
accesses one element past the end.
Fix the issues by using < instead of <=, ensuring we do not exceed
the bounds.
[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)
In the Linux kernel, the following vulnerability has been resolved:
e1000: fix OOB in e1000_tbi_should_accept()
In e1000_tbi_should_accept() we read the last byte of the frame via 'data[length - 1]' to evaluate the TBI workaround. If the descriptor- reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq):
================================================================== BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790 Read of size 1 at addr ffff888014114e54 by task sshd/363
CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 </IRQ> <TASK> __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f511b476b10 Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 </TASK> Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30 The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800] The buggy address belongs to the physical page: page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110 head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected ==================================================================
This happens because the TBI check unconditionally dereferences the last byte without validating the reported length first:
u8 last_byte = *(data + length - 1);
Fix by rejecting the frame early if the length is zero, or if it exceeds adapter->rx_buffer_len. This preserves the TBI workaround semantics for valid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Handle incorrect num_connectors capability
The UCSI spec states that the num_connectors field is 7 bits, and the 8th bit is reserved and should be set to zero. Some buggy FW has been known to set this bit, and it can lead to a system not booting. Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly.
Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported.(CVE-2025-71108)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - zero initialize memory allocated via sock_kmalloc
Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future.
The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures.
A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit:
67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")
Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:
https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209
The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.(CVE-2025-71113)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/kexec: Enable SMT before waking offline CPUs
If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed:
kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc [snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec
This occurs as add_cpu() fails due to cpu_bootable() returning false for CPUs that fail the cpu_smt_thread_allowed() check or non primary threads if SMT is disabled.
Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.(CVE-2025-71119)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Do not register unsupported perf events
Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:
------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:
# perf record -e synthetic:futex_wait Error: The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.
Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.(CVE-2025-71125)
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory and information leak in smb3_reconfigure()
In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak.
Fix this by calling kfree_sensitive() on both password buffers before returning in this error case.(CVE-2025-71151)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"perf-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-138.0.0.132.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-138.0.0.132.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"perf-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-138.0.0.132.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-138.0.0.132.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-138.0.0.132.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()\n\nJakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()\nto increase test coverage.\n\nsyzbot found a splat caused by hard irq blocking in\nptr_ring_resize_multiple() [1]\n\nAs current users of ptr_ring_resize_multiple() do not require\nhard irqs being masked, replace it to only block BH.\n\nRename helpers to better reflect they are safe against BH only.\n\n- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()\n- skb_array_resize_multiple() to skb_array_resize_multiple_bh()\n\n[1]\n\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nModules linked in:\nCPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]\nRIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nCode: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 \u0026lt;0f\u0026gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85\nRSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083\nRAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000\nRDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843\nRBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d\nR10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040\nR13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff\nFS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tun_ptr_free drivers/net/tun.c:617 [inline]\n __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline]\n ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline]\n tun_queue_resize drivers/net/tun.c:3694 [inline]\n tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714\n notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93\n call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]\n call_netdevice_notifiers net/core/dev.c:2046 [inline]\n dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024\n do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923\n rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201\n rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550(CVE-2024-57994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params\n\nEach cpu DAI should associate with a widget. However, the topology might\nnot create the right number of DAI widgets for aggregated amps. And it\nwill cause NULL pointer deference.\nCheck that the DAI widget associated with the CPU DAI is valid to prevent\nNULL pointer deference due to missing DAI widgets in topologies with\naggregated amps.(CVE-2024-58012)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential NULL pointer dereference in dev_uevent()\n\nIf userspace reads \u0026quot;uevent\u0026quot; device attribute at the same time as another\nthreads unbinds the device from its driver, change to dev-\u0026gt;driver from a\nvalid pointer to NULL may result in crash. Fix this by using READ_ONCE()\nwhen fetching the pointer, and take bus\u0026apos; drivers klist lock to make sure\ndriver instance will not disappear while we access it.\n\nUse WRITE_ONCE() when setting the driver pointer to ensure there is no\ntearing.(CVE-2025-37800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds clause 45 read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via C45 (clause 45) mdiobus,\nthere is no verification of parameters passed to the ioctl and\nit accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before C45 read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via mdiobus, there is no verification of\nparameters passed to the ioctl and it accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: clear phydev-\u0026gt;devlink when the link is deleted\n\nThere is a potential crash issue when disabling and re-enabling the\nnetwork port. When disabling the network port, phy_detach() calls\ndevice_link_del() to remove the device link, but it does not clear\nphydev-\u0026gt;devlink, so phydev-\u0026gt;devlink is not a NULL pointer. Then the\nnetwork port is re-enabled, but if phy_attach_direct() fails before\ncalling device_link_add(), the code jumps to the \u0026quot;error\u0026quot; label and\ncalls phy_detach(). Since phydev-\u0026gt;devlink retains the old value from\nthe previous attach/detach cycle, device_link_del() uses the old value,\nwhich accesses a NULL pointer and causes a crash. The simplified crash\nlog is as follows.\n\n[ 24.702421] Call trace:\n[ 24.704856] device_link_put_kref+0x20/0x120\n[ 24.709124] device_link_del+0x30/0x48\n[ 24.712864] phy_detach+0x24/0x168\n[ 24.716261] phy_attach_direct+0x168/0x3a4\n[ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c\n[ 24.725140] phylink_of_phy_connect+0x1c/0x34\n\nTherefore, phydev-\u0026gt;devlink needs to be cleared when the device link is\ndeleted.(CVE-2025-38149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: prevent overflow in lookup table allocation\n\nWhen calculating the lookup table size, ensure the following\nmultiplication does not overflow:\n\n- desc-\u0026gt;field_len[] maximum value is U8_MAX multiplied by\n NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.\n- NFT_PIPAPO_BUCKETS(f-\u0026gt;bb) is 2^8, worst case.\n- sizeof(unsigned long), from sizeof(*f-\u0026gt;lt), lt in\n struct nft_pipapo_field.\n\nThen, use check_mul_overflow() to multiply by bucket size and then use\ncheck_add_overflow() to the alignment for avx2 (if needed). Finally, add\nlt_size_check_overflow() helper and use it to consolidate this.\n\nWhile at it, replace leftover allocation using the GFP_KERNEL to\nGFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().(CVE-2025-38162)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: add NULL check in automount_fullpath\n\npage is checked for null in __build_path_from_dentry_optional_prefix\nwhen tcon-\u0026gt;origin_fullpath is not set. However, the check is missing when\nit is set.\nAdd a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix race between nfsd registration and exports_proc\n\nAs of now nfsd calls create_proc_exports_entry() at start of init_nfsd\nand cleanup by remove_proc_entry() at last of exit_nfsd.\n\nWhich causes kernel OOPs if there is race between below 2 operations:\n(i) exportfs -r\n(ii) mount -t nfsd none /proc/fs/nfsd\n\nfor 5.4 kernel ARM64:\n\nCPU 1:\nel1_irq+0xbc/0x180\narch_counter_get_cntvct+0x14/0x18\nrunning_clock+0xc/0x18\npreempt_count_add+0x88/0x110\nprep_new_page+0xb0/0x220\nget_page_from_freelist+0x2d8/0x1778\n__alloc_pages_nodemask+0x15c/0xef0\n__vmalloc_node_range+0x28c/0x478\n__vmalloc_node_flags_caller+0x8c/0xb0\nkvmalloc_node+0x88/0xe0\nnfsd_init_net+0x6c/0x108 [nfsd]\nops_init+0x44/0x170\nregister_pernet_operations+0x114/0x270\nregister_pernet_subsys+0x34/0x50\ninit_nfsd+0xa8/0x718 [nfsd]\ndo_one_initcall+0x54/0x2e0\n\nCPU 2 :\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000010\n\nPC is at : exports_net_open+0x50/0x68 [nfsd]\n\nCall trace:\nexports_net_open+0x50/0x68 [nfsd]\nexports_proc_open+0x2c/0x38 [nfsd]\nproc_reg_open+0xb8/0x198\ndo_dentry_open+0x1c4/0x418\nvfs_open+0x38/0x48\npath_openat+0x28c/0xf18\ndo_filp_open+0x70/0xe8\ndo_sys_open+0x154/0x248\n\nSometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().\n\nand same is happening on latest 6.14 kernel as well:\n\n[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty\n...\n[ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48\n...\n[ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4\n...\n[ 285.469695] Call trace:\n[ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)\n[ 285.470488] seq_read+0xe0/0x11c\n[ 285.470675] proc_reg_read+0x9c/0xf0\n[ 285.470874] vfs_read+0xc4/0x2fc\n[ 285.471057] ksys_read+0x6c/0xf4\n[ 285.471231] __arm64_sys_read+0x1c/0x28\n[ 285.471428] invoke_syscall+0x44/0x100\n[ 285.471633] el0_svc_common.constprop.0+0x40/0xe0\n[ 285.471870] do_el0_svc_compat+0x1c/0x34\n[ 285.472073] el0_svc_compat+0x2c/0x80\n[ 285.472265] el0t_32_sync_handler+0x90/0x140\n[ 285.472473] el0t_32_sync+0x19c/0x1a0\n[ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)\n[ 285.473422] ---[ end trace 0000000000000000 ]---\n\nIt reproduced simply with below script:\nwhile [ 1 ]\ndo\n/exportfs -r\ndone \u0026amp;\n\nwhile [ 1 ]\ndo\ninsmod /nfsd.ko\nmount -t nfsd none /proc/fs/nfsd\numount /proc/fs/nfsd\nrmmod nfsd\ndone \u0026amp;\n\nSo exporting interfaces to user space shall be done at last and\ncleanup at first place.\n\nWith change there is no Kernel OOPs.(CVE-2025-38232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential deadlock when reconnecting channels\n\nFix cifs_signal_cifsd_for_reconnect() to take the correct lock order\nand prevent the following deadlock from happening\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.16.0-rc3-build2+ #1301 Tainted: G S W\n------------------------------------------------------\ncifsd/6055 is trying to acquire lock:\nffff88810ad56038 (\u0026amp;tcp_ses-\u0026gt;srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200\n\nbut task is already holding lock:\nffff888119c64330 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}:\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_setup_session+0x81/0x4b0\n cifs_get_smb_ses+0x771/0x900\n cifs_mount_get_session+0x7e/0x170\n cifs_mount+0x92/0x2d0\n cifs_smb3_do_mount+0x161/0x460\n smb3_get_tree+0x55/0x90\n vfs_get_tree+0x46/0x180\n do_new_mount+0x1b0/0x2e0\n path_mount+0x6ee/0x740\n do_mount+0x98/0xe0\n __do_sys_mount+0x148/0x180\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #1 (\u0026amp;ret_buf-\u0026gt;ses_lock){+.+.}-{3:3}:\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_match_super+0x101/0x320\n sget+0xab/0x270\n cifs_smb3_do_mount+0x1e0/0x460\n smb3_get_tree+0x55/0x90\n vfs_get_tree+0x46/0x180\n do_new_mount+0x1b0/0x2e0\n path_mount+0x6ee/0x740\n do_mount+0x98/0xe0\n __do_sys_mount+0x148/0x180\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #0 (\u0026amp;tcp_ses-\u0026gt;srv_lock){+.+.}-{3:3}:\n check_noncircular+0x95/0xc0\n check_prev_add+0x115/0x2f0\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_signal_cifsd_for_reconnect+0x134/0x200\n __cifs_reconnect+0x8f/0x500\n cifs_handle_standard+0x112/0x280\n cifs_demultiplex_thread+0x64d/0xbc0\n kthread+0x2f7/0x310\n ret_from_fork+0x2a/0x230\n ret_from_fork_asm+0x1a/0x30\n\nother info that might help us debug this:\n\nChain exists of:\n \u0026amp;tcp_ses-\u0026gt;srv_lock --\u0026gt; \u0026amp;ret_buf-\u0026gt;ses_lock --\u0026gt; \u0026amp;ret_buf-\u0026gt;chan_lock\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;ret_buf-\u0026gt;chan_lock);\n lock(\u0026amp;ret_buf-\u0026gt;ses_lock);\n lock(\u0026amp;ret_buf-\u0026gt;chan_lock);\n lock(\u0026amp;tcp_ses-\u0026gt;srv_lock);\n\n *** DEADLOCK ***\n\n3 locks held by cifsd/6055:\n #0: ffffffff857de398 (\u0026amp;cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200\n #1: ffff888119c64060 (\u0026amp;ret_buf-\u0026gt;ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200\n #2: ffff888119c64330 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200(CVE-2025-38244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix possible crashes on eir_create_adv_data\n\neir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER\nwithout checking if that would fit.(CVE-2025-38303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoftware node: Correct a OOB check in software_node_get_reference_args()\n\nsoftware_node_get_reference_args() wants to get @index-th element, so\nthe property value requires at least \u0026apos;(index + 1) * sizeof(*ref)\u0026apos; bytes\nbut that can not be guaranteed by current OOB check, and may cause OOB\nfor malformed property.\n\nFix by using as OOB check \u0026apos;((index + 1) * sizeof(*ref) \u0026gt; prop-\u0026gt;length)\u0026apos;.(CVE-2025-38342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN\n\nWe found a few different systems hung up in writeback waiting on the same\npage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in\npnfs_update_layout(), however the pnfs_layout_hdr\u0026apos;s plh_outstanding count\nwas zero.\n\nIt seems most likely that this is another race between the waiter and waker\nsimilar to commit ed0172af5d6f (\u0026quot;SUNRPC: Fix a race to wake a sync task\u0026quot;).\nFix it up by applying the advised barrier.(CVE-2025-38393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight\n\nReject migration of SEV{-ES} state if either the source or destination VM\nis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the\nsection between incrementing created_vcpus and online_vcpus. The bulk of\nvCPU creation runs _outside_ of kvm-\u0026gt;lock to allow creating multiple vCPUs\nin parallel, and so sev_info.es_active can get toggled from false=\u0026gt;true in\nthe destination VM after (or during) svm_vcpu_create(), resulting in an\nSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.\n\nThe issue manifests most visibly as a crash when trying to free a vCPU\u0026apos;s\nNULL VMSA page in an SEV-ES VM, but any number of things can go wrong.\n\n BUG: unable to handle page fault for address: ffffebde00000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP KASAN NOPTI\n CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024\n RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]\n RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]\n RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]\n RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]\n RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067\n Code: \u0026lt;49\u0026gt; f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0\n RSP: 0018:ffff8984551978d0 EFLAGS: 00010246\n RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98\n RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000\n RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000\n R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000\n R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000\n FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0\n DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169\n svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515\n kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396\n kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]\n kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490\n kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895\n kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310\n kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369\n __fput+0x3e4/0x9e0 fs/file_table.c:465\n task_work_run+0x1a9/0x220 kernel/task_work.c:227\n exit_task_work include/linux/task_work.h:40 [inline]\n do_exit+0x7f0/0x25b0 kernel/exit.c:953\n do_group_exit+0x203/0x2d0 kernel/exit.c:1102\n get_signal+0x1357/0x1480 kernel/signal.c:3034\n arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218\n do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f87a898e969\n \u0026lt;/TASK\u0026gt;\n Modules linked in: gq(O)\n gsmi: Log Shutdown Reason 0x03\n CR2: ffffebde00000000\n ---[ end trace 0000000000000000 ]---\n\nDeliberately don\u0026apos;t check for a NULL VMSA when freeing the vCPU, as crashing\nthe host is likely desirable due to the VMSA being consumed by hardware.\nE.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a\nbogus VMSA page. Accessing P\n---truncated---(CVE-2025-38455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again\n\nCommit 7ded842b356d (\u0026quot;s390/bpf: Fix bpf_plt pointer arithmetic\u0026quot;) has\naccidentally removed the critical piece of commit c730fce7c70c\n(\u0026quot;s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL\u0026quot;), causing\nintermittent kernel panics in e.g. perf\u0026apos;s on_switch() prog to reappear.\n\nRestore the fix and add a comment.(CVE-2025-38489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Avoid stack buffer overflow from kernel cmdline\n\nWhile the kernel command line is considered trusted in most environments,\navoid writing 1 byte past the end of \u0026quot;acpiid\u0026quot; if the \u0026quot;str\u0026quot; argument is\nmaximum length.(CVE-2025-38676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Prevent ALIGN() overflow\n\nWhen allocating IOVA the candidate range gets aligned to the target\nalignment. If the range is close to ULONG_MAX then the ALIGN() can\nwrap resulting in a corrupted iova.\n\nOpen code the ALIGN() using get_add_overflow() to prevent this.\nThis simplifies the checks as we don\u0026apos;t need to check for length earlier\neither.\n\nConsolidate the two copies of this code under a single helper.\n\nThis bug would allow userspace to create a mapping that overlaps with some\nother mapping or a reserved range.(CVE-2025-38688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: upper bound check of tree index in dbAllocAG\n\nWhen computing the tree index in dbAllocAG, we never check if we are\nout of bounds realative to the size of the stree.\nThis could happen in a scenario where the filesystem metadata are\ncorrupted.(CVE-2025-38697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: don\u0026apos;t use BUG_ON() in hfsplus_create_attributes_file()\n\nWhen the volume header contains erroneous values that do not reflect\nthe actual state of the filesystem, hfsplus_fill_super() assumes that\nthe attributes file is not yet created, which later results in hitting\nBUG_ON() when hfsplus_create_attributes_file() is called. Replace this\nBUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nThe hfsplus_readdir() method is capable to crash by calling\nhfsplus_uni2asc():\n\n[ 667.121659][ T9805] ==================================================================\n[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10\n[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805\n[ 667.124578][ T9805]\n[ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)\n[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 667.124890][ T9805] Call Trace:\n[ 667.124893][ T9805] \u0026lt;TASK\u0026gt;\n[ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0\n[ 667.124911][ T9805] print_report+0xd0/0x660\n[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610\n[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180\n[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124942][ T9805] kasan_report+0xc6/0x100\n[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10\n[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360\n[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0\n[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10\n[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0\n[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0\n[ 667.125022][ T9805] ? lock_acquire+0x30/0x80\n[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0\n[ 667.125044][ T9805] ? putname+0x154/0x1a0\n[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10\n[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0\n[ 667.125069][ T9805] iterate_dir+0x296/0xb20\n[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10\n[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200\n[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10\n[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0\n[ 667.125143][ T9805] do_syscall_64+0xc9/0x480\n[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9\n[ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48\n[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9\n[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9\n[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004\n[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110\n[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260\n[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 667.125207][ T9805] \u0026lt;/TASK\u0026gt;\n[ 667.125210][ T9805]\n[ 667.145632][ T9805] Allocated by task 9805:\n[ 667.145991][ T9805] kasan_save_stack+0x20/0x40\n[ 667.146352][ T9805] kasan_save_track+0x14/0x30\n[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0\n[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550\n[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0\n[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0\n[ 667.148174][ T9805] iterate_dir+0x296/0xb20\n[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.148937][ T9805] do_syscall_64+0xc9/0x480\n[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.149809][ T9805]\n[ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000\n[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048\n[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of\n[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)\n[ 667.1\n---truncated---(CVE-2025-38713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()\n\nThe hfsplus_bnode_read() method can trigger the issue:\n\n[ 174.852007][ T9784] ==================================================================\n[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360\n[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784\n[ 174.854059][ T9784]\n[ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)\n[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 174.854286][ T9784] Call Trace:\n[ 174.854289][ T9784] \u0026lt;TASK\u0026gt;\n[ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0\n[ 174.854305][ T9784] print_report+0xd0/0x660\n[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610\n[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180\n[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854337][ T9784] kasan_report+0xc6/0x100\n[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360\n[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380\n[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10\n[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0\n[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310\n[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0\n[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0\n[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10\n[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10\n[ 174.854436][ T9784] ? __asan_memset+0x23/0x50\n[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320\n[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10\n[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0\n[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0\n[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10\n[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0\n[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10\n[ 174.854525][ T9784] ? down_write+0x148/0x200\n[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10\n[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0\n[ 174.854549][ T9784] do_unlinkat+0x490/0x670\n[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10\n[ 174.854565][ T9784] ? __might_fault+0xbc/0x130\n[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550\n[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110\n[ 174.854592][ T9784] do_syscall_64+0xc9/0x480\n[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167\n[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08\n[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057\n[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167\n[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50\n[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40\n[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0\n[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 174.854658][ T9784] \u0026lt;/TASK\u0026gt;\n[ 174.854661][ T9784]\n[ 174.879281][ T9784] Allocated by task 9784:\n[ 174.879664][ T9784] kasan_save_stack+0x20/0x40\n[ 174.880082][ T9784] kasan_save_track+0x14/0x30\n[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0\n[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550\n[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890\n[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10\n[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520\n[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3\n---truncated---(CVE-2025-38714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix for slab out of bounds on mount to ksmbd\n\nWith KASAN enabled, it is possible to get a slab out of bounds\nduring mount to ksmbd due to missing check in parse_server_interfaces()\n(see below):\n\n BUG: KASAN: slab-out-of-bounds in\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n Read of size 4 at addr ffff8881433dba98 by task mount/9827\n\n CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G\n OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary)\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,\n BIOS 2.13.1 06/14/2019\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x9f/0xf0\n print_report+0xd1/0x670\n __virt_addr_valid+0x22c/0x430\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? kasan_complete_mode_report_info+0x2a/0x1f0\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n kasan_report+0xd6/0x110\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n __asan_report_load_n_noabort+0x13/0x20\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]\n ? trace_hardirqs_on+0x51/0x60\n SMB3_request_interfaces+0x1ad/0x3f0 [cifs]\n ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]\n ? SMB2_tcon+0x23c/0x15d0 [cifs]\n smb3_qfs_tcon+0x173/0x2b0 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n cifs_mount_get_tcon+0x369/0xb90 [cifs]\n ? dfs_cache_find+0xe7/0x150 [cifs]\n dfs_mount_share+0x985/0x2970 [cifs]\n ? check_path.constprop.0+0x28/0x50\n ? save_trace+0x54/0x370\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? __lock_acquire+0xb82/0x2ba0\n ? __kasan_check_write+0x18/0x20\n cifs_mount+0xbc/0x9e0 [cifs]\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]\n cifs_smb3_do_mount+0x263/0x1990 [cifs](CVE-2025-38728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix refcount leak causing resource not released\n\nWhen ksmbd_conn_releasing(opinfo-\u0026gt;conn) returns true,the refcount was not\ndecremented properly, causing a refcount leak that prevents the count from\nreaching zero and the memory from being released.(CVE-2025-39720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - flush misc workqueue during device shutdown\n\nRepeated loading and unloading of a device specific QAT driver, for\nexample qat_4xxx, in a tight loop can lead to a crash due to a\nuse-after-free scenario. This occurs when a power management (PM)\ninterrupt triggers just before the device-specific driver (e.g.,\nqat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains\nloaded.\n\nSince the driver uses a shared workqueue (`qat_misc_wq`) across all\ndevices and owned by intel_qat.ko, a deferred routine from the\ndevice-specific driver may still be pending in the queue. If this\nroutine executes after the driver is unloaded, it can dereference freed\nmemory, resulting in a page fault and kernel crash like the following:\n\n BUG: unable to handle page fault for address: ffa000002e50a01c\n #PF: supervisor read access in kernel mode\n RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]\n Call Trace:\n pm_bh_handler+0x1d2/0x250 [intel_qat]\n process_one_work+0x171/0x340\n worker_thread+0x277/0x3a0\n kthread+0xf0/0x120\n ret_from_fork+0x2d/0x50\n\nTo prevent this, flush the misc workqueue during device shutdown to\nensure that all pending work items are completed before the driver is\nunloaded.\n\nNote: This approach may slightly increase shutdown latency if the\nworkqueue contains jobs from other devices, but it ensures correctness\nand stability.(CVE-2025-39721)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix filehandle bounds checking in nfs_fh_to_dentry()\n\nThe function needs to check the minimal filehandle length before it can\naccess the embedded filehandle.(CVE-2025-39730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel. Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects. The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue. In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn\u0026apos;t really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen. So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.(CVE-2025-39737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect -\u0026gt;defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won\u0026apos;t happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure\u0026apos;s -\u0026gt;defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special(). This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last enabled at (200272): [\u0026lt;ffffffffb0f56121\u0026gt;] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [\u0026lt;ffffffffb25c7859\u0026gt;] __schedule+0x129/0xd70\nsoftirqs last enabled at (0): [\u0026lt;ffffffffb0ee093f\u0026gt;] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special(). In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe -\u0026gt;defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the -\u0026gt;defer_qs_iw_pending\nfield. This suffices because this handler is not a fast path.(CVE-2025-39749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix the setting of capabilities when automounting a new filesystem\n\nCapabilities cannot be inherited when we cross into a new filesystem.\nThey need to be reset to the minimal defaults, and then probed for\nagain.(CVE-2025-39798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: use array_index_nospec with indices that come from guest\n\nmin and dest_id are guest-controlled indices. Using array_index_nospec()\nafter the bounds checks clamps these values to mitigate speculative execution\nside-channels.(CVE-2025-39823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().\n\nsyzbot reported the splat below. [0]\n\nWhen atmtcp_v_open() or atmtcp_v_close() is called via connect()\nor close(), atmtcp_send_control() is called to send an in-kernel\nspecial message.\n\nThe message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.\nAlso, a pointer of struct atm_vcc is set to atmtcp_control.vcc.\n\nThe notable thing is struct atmtcp_control is uAPI but has a\nspace for an in-kernel pointer.\n\n struct atmtcp_control {\n \tstruct atmtcp_hdr hdr;\t/* must be first */\n ...\n \tatm_kptr_t vcc;\t\t/* both directions */\n ...\n } __ATM_API_ALIGN;\n\n typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;\n\nThe special message is processed in atmtcp_recv_control() called\nfrom atmtcp_c_send().\n\natmtcp_c_send() is vcc-\u0026gt;dev-\u0026gt;ops-\u0026gt;send() and called from 2 paths:\n\n 1. .ndo_start_xmit() (vcc-\u0026gt;send() == atm_send_aal0())\n 2. vcc_sendmsg()\n\nThe problem is sendmsg() does not validate the message length and\nuserspace can abuse atmtcp_recv_control() to overwrite any kptr\nby atmtcp_control.\n\nLet\u0026apos;s add a new -\u0026gt;pre_send() hook to validate messages from sendmsg().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI\nKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]\nCPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]\nRIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297\nCode: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c\nRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203\nRAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c\nRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd\nR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000\nR13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff\nFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n ____sys_sendmsg+0x505/0x830 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f8d7e96a4a9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9\nRDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005\nRBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f\nR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac\nR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250\n \u0026lt;/TASK\u0026gt;\nModules linked in:(CVE-2025-39828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: prevent NULL pointer dereference in UTF16 conversion\n\nThere can be a NULL pointer dereference bug here. NULL is passed to\n__cifs_sfu_make_node without checks, which passes it unchecked to\ncifs_strndup_to_utf16, which in turn passes it to\ncifs_local_to_utf16_bytes where \u0026apos;*from\u0026apos; is dereferenced, causing a crash.\n\nThis patch adds a check for NULL \u0026apos;src\u0026apos; in cifs_strndup_to_utf16 and\nreturns NULL early to prevent dereferencing NULL pointer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix OOB read/write in network-coding decode\n\nbatadv_nc_skb_decode_packet() trusts coded_len and checks only against\nskb-\u0026gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing\npayload headroom, and the source skb length is not verified, allowing an\nout-of-bounds read and a small out-of-bounds write.\n\nValidate that coded_len fits within the payload area of both destination\nand source sk_buffs before XORing.(CVE-2025-39839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix race condition validating r_parent before applying state\n\nAdd validation to ensure the cached parent directory inode matches the\ndirectory info in MDS replies. This prevents client-side race conditions\nwhere concurrent operations (e.g. rename) cause r_parent to become stale\nbetween request initiation and reply processing, which could lead to\napplying state changes to incorrect directory inodes.\n\n[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to\n move CEPH_CAP_PIN reference when r_parent is updated:\n\n When the parent directory lock is not held, req-\u0026gt;r_parent can become\n stale and is updated to point to the correct inode. However, the\n associated CEPH_CAP_PIN reference was not being adjusted. The\n CEPH_CAP_PIN is a reference on an inode that is tracked for\n accounting purposes. Moving this pin is important to keep the\n accounting balanced. When the pin was not moved from the old parent\n to the new one, it created two problems: The reference on the old,\n stale parent was never released, causing a reference leak.\n A reference for the new parent was never acquired, creating the risk\n of a reference underflow later in ceph_mdsc_release_request(). This\n patch corrects the logic by releasing the pin from the old parent and\n acquiring it for the new parent when r_parent is switched. This\n ensures reference accounting stays balanced. ](CVE-2025-39927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path\n\nDuring tests of another unrelated patch I was able to trigger this\nerror: Objects remaining on __kmem_cache_shutdown()(CVE-2025-39929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: virtio_uml: Fix use-after-free after put_device in probe\n\nWhen register_virtio_device() fails in virtio_uml_probe(),\nthe code sets vu_dev-\u0026gt;registered = 1 even though\nthe device was not successfully registered.\nThis can lead to use-after-free or other issues.(CVE-2025-39951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix null-deref in agg_dequeue\n\nTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)\nwhen cl-\u0026gt;qdisc-\u0026gt;ops-\u0026gt;peek(cl-\u0026gt;qdisc) returns NULL, we check the return\nvalue before using it, similar to the existing approach in sch_hfsc.c.\n\nTo avoid code duplication, the following changes are made:\n\n1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static\ninline function.\n\n2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to\ninclude/net/pkt_sched.h so that sch_qfq can reuse it.\n\n3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Define a proc_layoutcommit for the FlexFiles layout type\n\nAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT\noperation on a FlexFiles layout.(CVE-2025-40087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: parse_dfs_referrals: prevent oob on malformed input\n\nMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS\n\n- reply smaller than sizeof(struct get_dfs_referral_rsp)\n- reply with number of referrals smaller than NumberOfReferrals in the\nheader\n\nProcessing of such replies will cause oob.\n\nReturn -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix refcount leak for cifs_sb_tlink\n\nFix three refcount inconsistency issues related to `cifs_sb_tlink`.\n\nComments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be\ncalled after successful calls to `cifs_sb_tlink()`. Three calls fail to\nupdate refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0026apos;t leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn\u0026apos;t point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\u0026quot;VFS: don\u0026apos;t keep disconnected dentries on d_anon\u0026quot;)\nwhich removed adding of most disconnected dentries to sb-\u0026gt;s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn\u0026apos;t marked as disconnected, as in the\nscenario described above, the reclaim doesn\u0026apos;t happen and the dentries\nare \u0026quot;leaked\u0026quot;. Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \u0026quot;Busy\ninodes after unmount\u0026quot; bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.(CVE-2025-40105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix Use-after-free in validation\n\nNodes stored in the validation duplicates hashtable come from an arena\nallocator that is cleared at the end of vmw_execbuf_process. All nodes\nare expected to be cleared in vmw_validation_drop_ht but this node escaped\nbecause its resource was destroyed prematurely.(CVE-2025-40111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Clean up only new IRQ glue on request_irq() failure\n\nThe mlx5_irq_alloc() function can inadvertently free the entire rmap\nand end up in a crash[1] when the other threads tries to access this,\nwhen request_irq() fails due to exhausted IRQ vectors. This commit\nmodifies the cleanup to remove only the specific IRQ mapping that was\njust added.\n\nThis prevents removal of other valid mappings and ensures precise\ncleanup of the failed IRQ allocation\u0026apos;s associated glue object.\n\nNote: This error is observed when both fwctl and rds configs are enabled.\n\n[1]\nmlx5_core 0000:05:00.0: Successfully registered panic handler for port 1\nmlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to\nrequest irq. err = -28\ninfiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while\ntrying to test write-combining support\nmlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1\nmlx5_core 0000:06:00.0: Successfully registered panic handler for port 1\nmlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to\nrequest irq. err = -28\ninfiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while\ntrying to test write-combining support\nmlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1\nmlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to\nrequest irq. err = -28\nmlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to\nrequest irq. err = -28\ngeneral protection fault, probably for non-canonical address\n0xe277a58fde16f291: 0000 [#1] SMP NOPTI\n\nRIP: 0010:free_irq_cpu_rmap+0x23/0x7d\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_trace_log_lvl+0x1d6/0x2f9\n ? show_trace_log_lvl+0x1d6/0x2f9\n ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]\n ? __die_body.cold+0x8/0xa\n ? die_addr+0x39/0x53\n ? exc_general_protection+0x1c4/0x3e9\n ? dev_vprintk_emit+0x5f/0x90\n ? asm_exc_general_protection+0x22/0x27\n ? free_irq_cpu_rmap+0x23/0x7d\n mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]\n irq_pool_request_vector+0x7d/0x90 [mlx5_core]\n mlx5_irq_request+0x2e/0xe0 [mlx5_core]\n mlx5_irq_request_vector+0xad/0xf7 [mlx5_core]\n comp_irq_request_pci+0x64/0xf0 [mlx5_core]\n create_comp_eq+0x71/0x385 [mlx5_core]\n ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core]\n mlx5_comp_eqn_get+0x72/0x90 [mlx5_core]\n ? xas_load+0x8/0x91\n mlx5_comp_irqn_get+0x40/0x90 [mlx5_core]\n mlx5e_open_channel+0x7d/0x3c7 [mlx5_core]\n mlx5e_open_channels+0xad/0x250 [mlx5_core]\n mlx5e_open_locked+0x3e/0x110 [mlx5_core]\n mlx5e_open+0x23/0x70 [mlx5_core]\n __dev_open+0xf1/0x1a5\n __dev_change_flags+0x1e1/0x249\n dev_change_flags+0x21/0x5c\n do_setlink+0x28b/0xcc4\n ? __nla_parse+0x22/0x3d\n ? inet6_validate_link_af+0x6b/0x108\n ? cpumask_next+0x1f/0x35\n ? __snmp6_fill_stats64.constprop.0+0x66/0x107\n ? __nla_validate_parse+0x48/0x1e6\n __rtnl_newlink+0x5ff/0xa57\n ? kmem_cache_alloc_trace+0x164/0x2ce\n rtnl_newlink+0x44/0x6e\n rtnetlink_rcv_msg+0x2bb/0x362\n ? __netlink_sendskb+0x4c/0x6c\n ? netlink_unicast+0x28f/0x2ce\n ? rtnl_calcit.isra.0+0x150/0x146\n netlink_rcv_skb+0x5f/0x112\n netlink_unicast+0x213/0x2ce\n netlink_sendmsg+0x24f/0x4d9\n __sock_sendmsg+0x65/0x6a\n ____sys_sendmsg+0x28f/0x2c9\n ? import_iovec+0x17/0x2b\n ___sys_sendmsg+0x97/0xe0\n __sys_sendmsg+0x81/0xd8\n do_syscall_64+0x35/0x87\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\nRIP: 0033:0x7fc328603727\nCode: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed\nff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00\nf0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48\nRSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727\nRDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d\nRBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\nR13: 00000000000\n---truncated---(CVE-2025-40250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()\n\nThe loops in \u0026apos;qede_tpa_cont()\u0026apos; and \u0026apos;qede_tpa_end()\u0026apos;, iterate\nover \u0026apos;cqe-\u0026gt;len_list[]\u0026apos; using only a zero-length terminator as\nthe stopping condition. If the terminator was missing or\nmalformed, the loop could run past the end of the fixed-size array.\n\nAdd an explicit bound check using ARRAY_SIZE() in both loops to prevent\na potential out-of-bounds access.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Do not sleep in atomic context\n\nsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may\nsleep. Hence, call sg_finish_rem_req() with interrupts enabled instead\nof disabled.(CVE-2025-40259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: nvme-fc: Ensure -\u0026gt;ioerr_work is cancelled in nvme_fc_delete_ctrl()\n\nnvme_fc_delete_assocation() waits for pending I/O to complete before\nreturning, and an error can cause -\u0026gt;ioerr_work to be queued after\ncancel_work_sync() had been called. Move the call to cancel_work_sync() to\nbe after nvme_fc_delete_association() to ensure -\u0026gt;ioerr_work is not running\nwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:\n\n[ 1135.911754] list_del corruption, ff2d24c8093f31f8-\u0026gt;next is NULL\n[ 1135.917705] ------------[ cut here ]------------\n[ 1135.922336] kernel BUG at lib/list_debug.c:52!\n[ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)\n[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025\n[ 1135.950969] Workqueue: 0x0 (nvme-wq)\n[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b\n[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046\n[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000\n[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0\n[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08\n[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100\n[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0\n[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000\n[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0\n[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[ 1136.055910] PKRU: 55555554\n[ 1136.058623] Call Trace:\n[ 1136.061074] \u0026lt;TASK\u0026gt;\n[ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.071898] ? move_linked_works+0x4a/0xa0\n[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.081744] ? __die_body.cold+0x8/0x12\n[ 1136.085584] ? die+0x2e/0x50\n[ 1136.088469] ? do_trap+0xca/0x110\n[ 1136.091789] ? do_error_trap+0x65/0x80\n[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.101289] ? exc_invalid_op+0x50/0x70\n[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20\n[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.120806] move_linked_works+0x4a/0xa0\n[ 1136.124733] worker_thread+0x216/0x3a0\n[ 1136.128485] ? __pfx_worker_thread+0x10/0x10\n[ 1136.132758] kthread+0xfa/0x240\n[ 1136.135904] ? __pfx_kthread+0x10/0x10\n[ 1136.139657] ret_from_fork+0x31/0x50\n[ 1136.143236] ? __pfx_kthread+0x10/0x10\n[ 1136.146988] ret_from_fork_asm+0x1a/0x30\n[ 1136.150915] \u0026lt;/TASK\u0026gt;(CVE-2025-40261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: pass wrb_params in case of OS2BMC\n\nbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULL\nat be_send_pkt_to_bmc() call site.\u00a0 This may lead to dereferencing a NULL\npointer when processing a workaround for specific packet, as commit\nbc0c3405abbb (\u0026quot;be2net: fix a Tx stall bug caused by a specific ipv6\npacket\u0026quot;) states.\n\nThe correct way would be to pass the wrb_params from be_xmit().(CVE-2025-40264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: client: fix memory leak in smb3_fs_context_parse_param\n\nThe user calls fsconfig twice, but when the program exits, free() only\nfrees ctx-\u0026gt;source for the second fsconfig, not the first.\nRegarding fc-\u0026gt;source, there is no code in the fs context related to its\nmemory reclamation.\n\nTo fix this memory leak, release the source memory corresponding to ctx\nor fc before each parsing.\n\nsyzbot reported:\nBUG: memory leak\nunreferenced object 0xffff888128afa360 (size 96):\n backtrace (crc 79c9c7ba):\n kstrdup+0x3c/0x80 mm/util.c:84\n smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444\n\nBUG: memory leak\nunreferenced object 0xffff888112c7d900 (size 96):\n backtrace (crc 79c9c7ba):\n smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629\n smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: free copynotify stateid in nfs4_free_ol_stateid()\n\nTypically copynotify stateid is freed either when parent\u0026apos;s stateid\nis being close/freed or in nfsd4_laundromat if the stateid hasn\u0026apos;t\nbeen used in a lease period.\n\nHowever, in case when the server got an OPEN (which created\na parent stateid), followed by a COPY_NOTIFY using that stateid,\nfollowed by a client reboot. New client instance while doing\nCREATE_SESSION would force expire previous state of this client.\nIt leads to the open state being freed thru release_openowner-\u0026gt;\nnfs4_free_ol_stateid() and it finds that it still has copynotify\nstateid associated with it. We currently print a warning and is\ntriggerred\n\nWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]\n\nThis patch, instead, frees the associated copynotify stateid here.\n\nIf the parent stateid is freed (without freeing the copynotify\nstateids associated with it), it leads to the list corruption\nwhen laundromat ends up freeing the copynotify state later.\n\n[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink\n[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)\n[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN\n[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024\n[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd]\n[ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.861182] sp : ffff8000881d7a40\n[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200\n[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20\n[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8\n[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000\n[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065\n[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3\n[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000\n[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001\n[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000\n[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d\n[ 1626.868167] Call trace:\n[ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)\n[ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd]\n[ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd]\n[ 1626.869813] laundromat_main+0x24/0x60 [nfsd]\n[ 1626.870231] process_one_work+0x584/0x1050\n[ 1626.870595] worker_thread+0x4c4/0xc60\n[ 1626.870893] kthread+0x2f8/0x398\n[ 1626.871146] ret_from_fork+0x10/0x20\n[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)\n[ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: cancel mesh send timer when hdev removed\n\nmesh_send_done timer is not canceled when hdev is removed, which causes\ncrash if the timer triggers after hdev is gone.\n\nCancel the timer when MGMT removes the hdev, like other MGMT timers.\n\nShould fix the BUG: sporadically seen by BlueZ test bot\n(in \u0026quot;Mesh - Send cancel - 1\u0026quot; test).\n\nLog:\n------\nBUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0\n...\nFreed by task 36:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3a/0x60\n __kasan_slab_free+0x43/0x70\n kfree+0x103/0x500\n device_release+0x9a/0x210\n kobject_put+0x100/0x1e0\n vhci_release+0x18b/0x240\n------(CVE-2025-40284)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds\n\nAdd bounds checking to prevent writes past framebuffer boundaries when\nrendering text near screen edges. Return early if the Y position is off-screen\nand clip image height to screen boundary. Break from the rendering loop if the\nX position is off-screen. When clipping image width to fit the screen, update\nthe character count to match the clipped width to prevent buffer size\nmismatches.\n\nWithout the character count update, bit_putcs_aligned and bit_putcs_unaligned\nreceive mismatched parameters where the buffer is allocated for the clipped\nwidth but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naccel/habanalabs: support mapping cb with vmalloc-backed coherent memory\n\nWhen IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return\naddresses from the vmalloc range. If such an address is mapped without\nVM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the\nVM_PFNMAP restriction.\n\nFix this by checking for vmalloc addresses and setting VM_MIXEDMAP\nin the VMA before mapping. This ensures safe mapping and avoids kernel\ncrashes. The memory is still driver-allocated and cannot be accessed\ndirectly by userspace.(CVE-2025-40311)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget\n\nIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget\nstructure (pdev-\u0026gt;gadget) was freed before its endpoints.\nThe endpoints are linked via the ep_list in the gadget structure.\nFreeing the gadget first leaves dangling pointers in the endpoint list.\nWhen the endpoints are subsequently freed, this results in a use-after-free.\n\nFix:\nBy separating the usb_del_gadget_udc() operation into distinct \u0026quot;del\u0026quot; and\n\u0026quot;put\u0026quot; steps, cdnsp_gadget_free_endpoints() can be executed prior to the\nfinal release of the gadget structure with usb_put_gadget().\n\nA patch similar to bb9c74a5bd14(\u0026quot;usb: dwc3: gadget: Free gadget structure\n only after freeing endpoints\u0026quot;).(CVE-2025-40314)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Sync pending IRQ work before freeing ring buffer\n\nFix a race where irq_work can be queued in bpf_ringbuf_commit()\nbut the ring buffer is freed before the work executes.\nIn the syzbot reproducer, a BPF program attached to sched_switch\ntriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer\nis freed before this work executes, the irq_work thread may accesses\nfreed memory.\nCalling `irq_work_sync(\u0026amp;rb-\u0026gt;work)` ensures that all pending irq_work\ncomplete before freeing the buffer.(CVE-2025-40319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential cfid UAF in smb2_query_info_compound\n\nWhen smb2_query_info_compound() retries, a previously allocated cfid may\nhave been freed in the first attempt.\nBecause cfid wasn\u0026apos;t reset on replay, later cleanup could act on a stale\npointer, leading to a potential use-after-free.\n\nReinitialize cfid to NULL under the replay label.\n\nExample trace (trimmed):\n\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110\n[...]\nRIP: 0010:refcount_warn_saturate+0x9c/0x110\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n ? step_into+0x10d/0x690\n ? __legitimize_path+0x28/0x60\n smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n ? kmem_cache_alloc+0x18a/0x340\n ? getname_flags+0x46/0x1e0\n cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n statfs_by_dentry+0x67/0x90\n vfs_statfs+0x16/0xd0\n user_statfs+0x54/0xa0\n __do_sys_statfs+0x20/0x50\n do_syscall_64+0x58/0x80(CVE-2025-40320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: bitblit: bound-check glyph index in bit_putcs*\n\nbit_putcs_aligned()/unaligned() derived the glyph pointer from the\ncharacter value masked by 0xff/0x1ff, which may exceed the actual font\u0026apos;s\nglyph count and read past the end of the built-in font array.\nClamp the index to the actual glyph count before computing the address.\n\nThis fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Fix crash in nfsd4_read_release()\n\nWhen tracing is enabled, the trace_nfsd_read_done trace point\ncrashes during the pynfs read.testNoFh test.(CVE-2025-40324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in smb2_close_cached_fid()\n\nfind_or_create_cached_dir() could grab a new reference after kref_put()\nhad seen the refcount drop to zero but before cfid_list_lock is acquired\nin smb2_close_cached_fid(), leading to use-after-free.\n\nSwitch to kref_put_lock() so cfid_release() is called with\ncfid_list_lock held, closing that gap.(CVE-2025-40328)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: sddr55: Reject out-of-bound new_pba\n\nDiscovered by Atuin - Automated Vulnerability Discovery Engine.\n\nnew_pba comes from the status packet returned after each write.\nA bogus device could report values beyond the block count derived\nfrom info-\u0026gt;capacity, letting the driver walk off the end of\npba_to_lba[] and corrupt heap memory.\n\nReject PBAs that exceed the computed block count and fail the\ntransfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ\n\nXDP programs can change the layout of an xdp_buff through\nbpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver\ncannot assume the size of the linear data area nor fragments. Fix the\nbug in mlx5 by generating skb according to xdp_buff after XDP programs\nrun.\n\nCurrently, when handling multi-buf XDP, the mlx5 driver assumes the\nlayout of an xdp_buff to be unchanged. That is, the linear data area\ncontinues to be empty and fragments remain the same. This may cause\nthe driver to generate erroneous skb or triggering a kernel\nwarning. When an XDP program added linear data through\nbpf_xdp_adjust_head(), the linear data will be ignored as\nmlx5e_build_linear_skb() builds an skb without linear data and then\npull data from fragments to fill the linear data area. When an XDP\nprogram has shrunk the non-linear data through bpf_xdp_adjust_tail(),\nthe delta passed to __pskb_pull_tail() may exceed the actual nonlinear\ndata size and trigger the BUG_ON in it.\n\nTo fix the issue, first record the original number of fragments. If the\nnumber of fragments changes after the XDP program runs, rewind the end\nfragment pointer by the difference and recalculate the truesize. Then,\nbuild the skb with the linear data area matching the xdp_buff. Finally,\nonly pull data in if there is non-linear data and fill the linear part\nup to 256 bytes.(CVE-2025-40350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sysfb: Do not dereference NULL pointer in plane reset\n\nThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not\nderef that pointer, but forward NULL to the other plane-reset helpers.\nClears plane-\u0026gt;state to NULL.\n\nv2:\n- fix typo in commit description (Javier)(CVE-2025-40360)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: fix field-spanning memcpy warning in AH output\n\nFix field-spanning memcpy warnings in ah6_output() and\nah6_output_done() where extension headers are copied to/from IPv6\naddress fields, triggering fortify-string warnings about writes beyond\nthe 16-byte address fields.\n\n memcpy: detected field-spanning write (size 40) of single field \u0026quot;\u0026amp;top_iph-\u0026gt;saddr\u0026quot; at net/ipv6/ah6.c:439 (size 16)\n WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439\n\nThe warnings are false positives as the extension headers are\nintentionally placed after the IPv6 header in memory. Fix by properly\ncopying addresses and extension headers separately, and introduce\nhelper functions to avoid code duplication.(CVE-2025-40363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix possible deadlock while configuring policy\n\nFollowing deadlock can be triggered easily by lockdep:\n\nWARNING: possible circular locking dependency detected\n6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted\n------------------------------------------------------\ncheck/1334 is trying to acquire lock:\nff1100011d9d0678 (\u0026amp;q-\u0026gt;sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180\n\nbut task is already holding lock:\nff1100011d9d00e0 (\u0026amp;q-\u0026gt;q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;q-\u0026gt;q_usage_counter(queue)#3){++++}-{0:0}:\n blk_queue_enter+0x40b/0x470\n blkg_conf_prep+0x7b/0x3c0\n tg_set_limit+0x10a/0x3e0\n cgroup_file_write+0xc6/0x420\n kernfs_fop_write_iter+0x189/0x280\n vfs_write+0x256/0x490\n ksys_write+0x83/0x190\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x4608/0x4630\n do_syscall_64+0xdb/0x6b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #1 (\u0026amp;q-\u0026gt;rq_qos_mutex){+.+.}-{4:4}:\n __mutex_lock+0xd8/0xf50\n mutex_lock_nested+0x2b/0x40\n wbt_init+0x17e/0x280\n wbt_enable_default+0xe9/0x140\n blk_register_queue+0x1da/0x2e0\n __add_disk+0x38c/0x5d0\n add_disk_fwnode+0x89/0x250\n device_add_disk+0x18/0x30\n virtblk_probe+0x13a3/0x1800\n virtio_dev_probe+0x389/0x610\n really_probe+0x136/0x620\n __driver_probe_device+0xb3/0x230\n driver_probe_device+0x2f/0xe0\n __driver_attach+0x158/0x250\n bus_for_each_dev+0xa9/0x130\n driver_attach+0x26/0x40\n bus_add_driver+0x178/0x3d0\n driver_register+0x7d/0x1c0\n __register_virtio_driver+0x2c/0x60\n virtio_blk_init+0x6f/0xe0\n do_one_initcall+0x94/0x540\n kernel_init_freeable+0x56a/0x7b0\n kernel_init+0x2b/0x270\n ret_from_fork+0x268/0x4c0\n ret_from_fork_asm+0x1a/0x30\n\n-\u0026gt; #0 (\u0026amp;q-\u0026gt;sysfs_lock){+.+.}-{4:4}:\n __lock_acquire+0x1835/0x2940\n lock_acquire+0xf9/0x450\n __mutex_lock+0xd8/0xf50\n mutex_lock_nested+0x2b/0x40\n blk_unregister_queue+0x53/0x180\n __del_gendisk+0x226/0x690\n del_gendisk+0xba/0x110\n sd_remove+0x49/0xb0 [sd_mod]\n device_remove+0x87/0xb0\n device_release_driver_internal+0x11e/0x230\n device_release_driver+0x1a/0x30\n bus_remove_device+0x14d/0x220\n device_del+0x1e1/0x5a0\n __scsi_remove_device+0x1ff/0x2f0\n scsi_remove_device+0x37/0x60\n sdev_store_delete+0x77/0x100\n dev_attr_store+0x1f/0x40\n sysfs_kf_write+0x65/0x90\n kernfs_fop_write_iter+0x189/0x280\n vfs_write+0x256/0x490\n ksys_write+0x83/0x190\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x4608/0x4630\n do_syscall_64+0xdb/0x6b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nother info that might help us debug this:\n\nChain exists of:\n \u0026amp;q-\u0026gt;sysfs_lock --\u0026gt; \u0026amp;q-\u0026gt;rq_qos_mutex --\u0026gt; \u0026amp;q-\u0026gt;q_usage_counter(queue)#3\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;q-\u0026gt;q_usage_counter(queue)#3);\n lock(\u0026amp;q-\u0026gt;rq_qos_mutex);\n lock(\u0026amp;q-\u0026gt;q_usage_counter(queue)#3);\n lock(\u0026amp;q-\u0026gt;sysfs_lock);\n\nRoot cause is that queue_usage_counter is grabbed with rq_qos_mutex\nheld in blkg_conf_prep(), while queue should be freezed before\nrq_qos_mutex from other context.\n\nThe blk_queue_enter() from blkg_conf_prep() is used to protect against\npolicy deactivation, which is already protected with blkcg_mutex, hence\nconvert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,\nconsider that blkcg_mutex is held after queue is freezed from policy\ndeactivation, also convert blkg_alloc() to use GFP_NOIO.(CVE-2025-68178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Disable AFBC support on Mediatek DRM driver\n\nCommit c410fa9b07c3 (\u0026quot;drm/mediatek: Add AFBC support to Mediatek DRM\ndriver\u0026quot;) added AFBC support to Mediatek DRM and enabled the\n32x8/split/sparse modifier.\n\nHowever, this is currently broken on Mediatek MT8188 (Genio 700 EVK\nplatform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by\ndefault since Mesa v25.0.\n\nKernel trace reports vblank timeouts constantly, and the render is garbled:\n\n```\n[CRTC:62:crtc-0] vblank wait timed out\nWARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\n[...]\nHardware name: MediaTek Genio-700 EVK (DT)\nWorkqueue: events_unbound commit_work\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nlr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nsp : ffff80008337bca0\nx29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000\nx26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000\nx23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80\nx20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a\nx17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000\nx14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b\nx11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70\nx8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70\nx5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480\nCall trace:\n drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)\n drm_atomic_helper_commit_tail_rpm+0x64/0x80\n commit_tail+0xa4/0x1a4\n commit_work+0x14/0x20\n process_one_work+0x150/0x290\n worker_thread+0x2d0/0x3ec\n kthread+0x12c/0x210\n ret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\n```\n\nUntil this gets fixed upstream, disable AFBC support on this platform, as\nit\u0026apos;s currently broken with upstream Mesa.(CVE-2025-68184)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs4_setup_readdir(): insufficient locking for -\u0026gt;d_parent-\u0026gt;d_inode dereferencing\n\nTheoretically it\u0026apos;s an oopsable race, but I don\u0026apos;t believe one can manage\nto hit it on real hardware; might become doable on a KVM, but it still\nwon\u0026apos;t be easy to attack.\n\nAnyway, it\u0026apos;s easy to deal with - since xdr_encode_hyper() is just a call of\nput_unaligned_be64(), we can put that under -\u0026gt;d_lock and be done with that.(CVE-2025-68185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp_tunnel: use netdev_warn() instead of netdev_WARN()\n\nnetdev_WARN() uses WARN/WARN_ON to print a backtrace along with\nfile and line information. In this case, udp_tunnel_nic_register()\nreturning an error is just a failed operation, not a kernel bug.\n\nudp_tunnel_nic_register() can fail due to a memory allocation\nfailure (kzalloc() or udp_tunnel_nic_alloc()).\nThis is a normal runtime error and not a kernel bug.\n\nReplace netdev_WARN() with netdev_warn() accordingly.(CVE-2025-68191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: fix lockdep WARN due to partition scan work\n\nBlktests test cases nvme/014, 057 and 058 fail occasionally due to a\nlockdep WARN. As reported in the Closes tag URL, the WARN indicates that\na deadlock can happen due to the dependency among disk-\u0026gt;open_mutex,\nkblockd workqueue completion and partition_scan_work completion.\n\nTo avoid the lockdep WARN and the potential deadlock, cut the dependency\nby running the partition_scan_work not by kblockd workqueue but by\nnvme_wq.(CVE-2025-68218)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix memory leak in smb3_fs_context_parse_param error path\n\nAdd proper cleanup of ctx-\u0026gt;source and fc-\u0026gt;source to the\ncifs_parse_mount_err error handler. This ensures that memory allocated\nfor the source strings is correctly freed on all error paths, matching\nthe cleanup already performed in the success path by\nsmb3_cleanup_fs_context_contents().\nPointers are also set to NULL after freeing to prevent potential\ndouble-free issues.\n\nThis change fixes a memory leak originally detected by syzbot. The\nleak occurred when processing Opt_source mount options if an error\nhappened after ctx-\u0026gt;source and fc-\u0026gt;source were successfully\nallocated but before the function completed.\n\nThe specific leak sequence was:\n1. ctx-\u0026gt;source = smb3_fs_context_fullpath(ctx, \u0026apos;/\u0026apos;) allocates memory\n2. fc-\u0026gt;source = kstrdup(ctx-\u0026gt;source, GFP_KERNEL) allocates more memory\n3. A subsequent error jumps to cifs_parse_mount_err\n4. The old error handler freed passwords but not the source strings,\ncausing the memory to leak.\n\nThis issue was not addressed by commit e8c73eb7db0a (\u0026quot;cifs: client:\nfix memory leak in smb3_fs_context_parse_param\u0026quot;), which only fixed\nleaks from repeated fsconfig() calls but not this error path.\n\nPatch updated with minor change suggested by kernel test robot(CVE-2025-68219)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()\n\nIf the allocation of tl_hba-\u0026gt;sh fails in tcm_loop_driver_probe() and we\nattempt to dereference it in tcm_loop_tpg_address_show() we will get a\nsegfault, see below for an example. So, check tl_hba-\u0026gt;sh before\ndereferencing it.\n\n Unable to allocate struct scsi_host\n BUG: kernel NULL pointer dereference, address: 0000000000000194\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1\n Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024\n RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]\n...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n configfs_read_iter+0x12d/0x1d0 [configfs]\n vfs_read+0x1b5/0x300\n ksys_read+0x6f/0xf0\n...(CVE-2025-68229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: restore write access before closing files opened by open_exec()\n\nbm_register_write() opens an executable file using open_exec(), which\ninternally calls do_open_execat() and denies write access on the file to\navoid modification while it is being executed.\n\nHowever, when an error occurs, bm_register_write() closes the file using\nfilp_close() directly. This does not restore the write permission, which\nmay cause subsequent write operations on the same file to fail.\n\nFix this by calling exe_file_allow_write_access() before filp_close() to\nrestore the write permission properly.(CVE-2025-68239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe\n\nThe sit driver\u0026apos;s packet transmission path calls: sit_tunnel_xmit() -\u0026gt;\nupdate_or_create_fnhe(), which lead to fnhe_remove_oldest() being called\nto delete entries exceeding FNHE_RECLAIM_DEPTH+random.\n\nThe race window is between fnhe_remove_oldest() selecting fnheX for\ndeletion and the subsequent kfree_rcu(). During this time, the\nconcurrent path\u0026apos;s __mkroute_output() -\u0026gt; find_exception() can fetch the\nsoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a\nnew dst using a dst_hold(). When the original fnheX is freed via RCU,\nthe dst reference remains permanently leaked.\n\nCPU 0 CPU 1\n__mkroute_output()\n find_exception() [fnheX]\n update_or_create_fnhe()\n fnhe_remove_oldest() [fnheX]\n rt_bind_exception() [bind dst]\n RCU callback [fnheX freed, dst leak]\n\nThis issue manifests as a device reference count leak and a warning in\ndmesg when unregistering the net device:\n\n unregister_netdevice: waiting for sitX to become free. Usage count = N\n\nIdo Schimmel provided the simple test validation method [1].\n\nThe fix clears \u0026apos;oldest-\u0026gt;fnhe_daddr\u0026apos; before calling fnhe_flush_routes().\nSince rt_bind_exception() checks this field, setting it to zero prevents\nthe stale fnhe from being reused and bound to a new dst just before it\nis freed.\n\n[1]\nip netns add ns1\nip -n ns1 link set dev lo up\nip -n ns1 address add 192.0.2.1/32 dev lo\nip -n ns1 link add name dummy1 up type dummy\nip -n ns1 route add 192.0.2.2/32 dev dummy1\nip -n ns1 link add name gretap1 up arp off type gretap \\\n local 192.0.2.1 remote 192.0.2.2\nip -n ns1 route add 198.51.0.0/16 dev gretap1\ntaskset -c 0 ip netns exec ns1 mausezahn gretap1 \\\n -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q \u0026amp;\ntaskset -c 2 ip netns exec ns1 mausezahn gretap1 \\\n -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q \u0026amp;\nsleep 10\nip netns pids ns1 | xargs kill\nip netns del ns1(CVE-2025-68241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: netpoll: fix incorrect refcount handling causing incorrect cleanup\n\ncommit efa95b01da18 (\u0026quot;netpoll: fix use after free\u0026quot;) incorrectly\nignored the refcount and prematurely set dev-\u0026gt;npinfo to NULL during\nnetpoll cleanup, leading to improper behavior and memory leaks.\n\nScenario causing lack of proper cleanup:\n\n1) A netpoll is associated with a NIC (e.g., eth0) and netdev-\u0026gt;npinfo is\n allocated, and refcnt = 1\n - Keep in mind that npinfo is shared among all netpoll instances. In\n this case, there is just one.\n\n2) Another netpoll is also associated with the same NIC and\n npinfo-\u0026gt;refcnt += 1.\n - Now dev-\u0026gt;npinfo-\u0026gt;refcnt = 2;\n - There is just one npinfo associated to the netdev.\n\n3) When the first netpolls goes to clean up:\n - The first cleanup succeeds and clears np-\u0026gt;dev-\u0026gt;npinfo, ignoring\n refcnt.\n - It basically calls `RCU_INIT_POINTER(np-\u0026gt;dev-\u0026gt;npinfo, NULL);`\n - Set dev-\u0026gt;npinfo = NULL, without proper cleanup\n - No -\u0026gt;ndo_netpoll_cleanup() is either called\n\n4) Now the second target tries to clean up\n - The second cleanup fails because np-\u0026gt;dev-\u0026gt;npinfo is already NULL.\n * In this case, ops-\u0026gt;ndo_netpoll_cleanup() was never called, and\n the skb pool is not cleaned as well (for the second netpoll\n instance)\n - This leaks npinfo and skbpool skbs, which is clearly reported by\n kmemleak.\n\nRevert commit efa95b01da18 (\u0026quot;netpoll: fix use after free\u0026quot;) and adds\nclarifying comments emphasizing that npinfo cleanup should only happen\nonce the refcount reaches zero, ensuring stable and correct netpoll\nbehavior.(CVE-2025-68245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: avoid infinite loops due to corrupted subpage compact indexes\n\nRobert reported an infinite loop observed by two crafted images.\n\nThe root cause is that `clusterofs` can be larger than `lclustersize`\nfor !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:\n\n blocksize = lclustersize = 512 lcn = 6 clusterofs = 515\n\nMove the corresponding check for full compress indexes to\n`z_erofs_load_lcluster_from_disk()` to also cover subpage compact\ncompress indexes.\n\nIt also fixes the position of `m-\u0026gt;type \u0026gt;= Z_EROFS_LCLUSTER_TYPE_MAX`\ncheck, since it should be placed right after\n`z_erofs_load_{compact,full}_lcluster()`.(CVE-2025-68251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: Fix memory leak in USB bulk transport\n\nA kernel memory leak was identified by the \u0026apos;ioctl_sg01\u0026apos; test from Linux\nTest Project (LTP). The following bytes were mainly observed: 0x53425355.\n\nWhen USB storage devices incorrectly skip the data phase with status data,\nthe code extracts/validates the CSW from the sg buffer, but fails to clear\nit afterwards. This leaves status protocol data in srb\u0026apos;s transfer buffer,\nsuch as the US_BULK_CS_SIGN \u0026apos;USBS\u0026apos; signature observed here. Thus, this can\nlead to USB protocols leaks to user space through SCSI generic (/dev/sg*)\ninterfaces, such as the one seen here when the LTP test requested 512 KiB.\n\nFix the leak by zeroing the CSW data in srb\u0026apos;s transfer buffer immediately\nafter the validation of devices that skip data phase.\n\nNote: Differently from CVE-2018-1000204, which fixed a big leak by zero-\ning pages at allocation time, this leak occurs after allocation, when USB\nprotocol data is written to already-allocated sg pages.(CVE-2025-68288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix memory leak in cifs_construct_tcon()\n\nWhen having a multiuser mount with domain= specified and using\ncifscreds, cifs_set_cifscreds() will end up setting @ctx-\u0026gt;domainname,\nso it needs to be freed before leaving cifs_construct_tcon().\n\nThis fixes the following memory leak reported by kmemleak:\n\n mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...\n su - testuser\n cifscreds add -d ZELDA -u testuser\n ...\n ls /mnt/1\n ...\n umount /mnt\n echo scan \u0026gt; /sys/kernel/debug/kmemleak\n cat /sys/kernel/debug/kmemleak\n unreferenced object 0xffff8881203c3f08 (size 8):\n comm \u0026quot;ls\u0026quot;, pid 5060, jiffies 4307222943\n hex dump (first 8 bytes):\n 5a 45 4c 44 41 00 cc cc ZELDA...\n backtrace (crc d109a8cf):\n __kmalloc_node_track_caller_noprof+0x572/0x710\n kstrdup+0x3a/0x70\n cifs_sb_tlink+0x1209/0x1770 [cifs]\n cifs_get_fattr+0xe1/0xf50 [cifs]\n cifs_get_inode_info+0xb5/0x240 [cifs]\n cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]\n cifs_getattr+0x28e/0x450 [cifs]\n vfs_getattr_nosec+0x126/0x180\n vfs_statx+0xf6/0x220\n do_statx+0xab/0x110\n __x64_sys_statx+0xd5/0x130\n do_syscall_64+0xbb/0x380\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-68295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup\n\nProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOB\naccess in fbcon_remap_all(). Without holding the console lock the call\nraces with switching outputs.\n\nVGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon\nfunction uses struct fb_info.node, which is set by register_framebuffer().\nAs the fb-helper code currently sets up VGA switcheroo before registering\nthe framebuffer, the value of node is -1 and therefore not a legal value.\nFor example, fbcon uses the value within set_con2fb_map() [1] as an index\ninto an array.\n\nMoving vga_switcheroo_client_fb_set() after register_framebuffer() can\nresult in VGA switching that does not switch fbcon correctly.\n\nTherefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),\nwhich already holds the console lock. Fbdev calls fbcon_fb_registered()\nfrom within register_framebuffer(). Serializes the helper with VGA\nswitcheroo\u0026apos;s call to fbcon_remap_all().\n\nAlthough vga_switcheroo_client_fb_set() takes an instance of struct fb_info\nas parameter, it really only needs the contained fbcon state. Moving the\ncall to fbcon initialization is therefore cleaner than before. Only amdgpu,\ni915, nouveau and radeon support vga_switcheroo. For all other drivers,\nthis change does nothing.(CVE-2025-68296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sock: Prevent race in socket write iter and sock bind\n\nThere is a potential race condition between sock bind and socket write\niter. bind may free the same cmd via mgmt_pending before write iter sends\nthe cmd, just as syzbot reported in UAF[1].\n\nHere we use hci_dev_lock to synchronize the two, thereby avoiding the\nUAF mentioned in [1].\n\n[1]\nsyzbot reported:\nBUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316\nRead of size 8 at addr ffff888077164818 by task syz.0.17/5989\nCall Trace:\n mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316\n set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n sock_write_iter+0x279/0x360 net/socket.c:1195\n\nAllocated by task 5989:\n mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296\n set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n sock_write_iter+0x279/0x360 net/socket.c:1195\n\nFreed by task 5991:\n mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]\n mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257\n mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477\n hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump\n\nDo not block PCI config accesses through pci_cfg_access_lock() when\nexecuting the s390 variant of PCI error recovery: Acquire just\ndevice_lock() instead of pci_dev_lock() as powerpc\u0026apos;s EEH and\ngenerig PCI AER processing do.\n\nDuring error recovery testing a pair of tasks was reported to be hung:\n\nmlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working\nINFO: task kmcheck:72 blocked for more than 122 seconds.\n Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000\nCall Trace:\n [\u0026lt;000000065256f030\u0026gt;] __schedule+0x2a0/0x590\n [\u0026lt;000000065256f356\u0026gt;] schedule+0x36/0xe0\n [\u0026lt;000000065256f572\u0026gt;] schedule_preempt_disabled+0x22/0x30\n [\u0026lt;0000000652570a94\u0026gt;] __mutex_lock.constprop.0+0x484/0x8a8\n [\u0026lt;000003ff800673a4\u0026gt;] mlx5_unload_one+0x34/0x58 [mlx5_core]\n [\u0026lt;000003ff8006745c\u0026gt;] mlx5_pci_err_detected+0x94/0x140 [mlx5_core]\n [\u0026lt;0000000652556c5a\u0026gt;] zpci_event_attempt_error_recovery+0xf2/0x398\n [\u0026lt;0000000651b9184a\u0026gt;] __zpci_event_error+0x23a/0x2c0\nINFO: task kworker/u1664:6:1514 blocked for more than 122 seconds.\n Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000\nWorkqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]\nCall Trace:\n [\u0026lt;000000065256f030\u0026gt;] __schedule+0x2a0/0x590\n [\u0026lt;000000065256f356\u0026gt;] schedule+0x36/0xe0\n [\u0026lt;0000000652172e28\u0026gt;] pci_wait_cfg+0x80/0xe8\n [\u0026lt;0000000652172f94\u0026gt;] pci_cfg_access_lock+0x74/0x88\n [\u0026lt;000003ff800916b6\u0026gt;] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core]\n [\u0026lt;000003ff80098824\u0026gt;] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core]\n [\u0026lt;000003ff80074b62\u0026gt;] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core]\n [\u0026lt;0000000652512242\u0026gt;] devlink_health_do_dump.part.0+0x82/0x168\n [\u0026lt;0000000652513212\u0026gt;] devlink_health_report+0x19a/0x230\n [\u0026lt;000003ff80075a12\u0026gt;] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]\n\nNo kernel log of the exact same error with an upstream kernel is\navailable - but the very same deadlock situation can be constructed there,\ntoo:\n\n- task: kmcheck\n mlx5_unload_one() tries to acquire devlink lock while the PCI error\n recovery code has set pdev-\u0026gt;block_cfg_access by way of\n pci_cfg_access_lock()\n- task: kworker\n mlx5_crdump_collect() tries to set block_cfg_access through\n pci_cfg_access_lock() while devlink_health_report() had acquired\n the devlink lock.\n\nA similar deadlock situation can be reproduced by requesting a\ncrdump with\n \u0026gt; devlink health dump show pci/\u0026lt;BDF\u0026gt; reporter fw_fatal\n\nwhile PCI error recovery is executed on the same \u0026lt;BDF\u0026gt; physical function\nby mlx5_core\u0026apos;s pci_error_handlers. On s390 this can be injected with\n \u0026gt; zpcictl --reset-fw \u0026lt;BDF\u0026gt;\n\nTests with this patch failed to reproduce that second deadlock situation,\nthe devlink command is rejected with \u0026quot;kernel answers: Permission denied\u0026quot; -\nand we get a kernel log message of:\n\nmlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5\n\nbecause the config read of VSC_SEMAPHORE is rejected by the underlying\nhardware.\n\nTwo prior attempts to address this issue have been discussed and\nultimately rejected [see link], with the primary argument that s390\u0026apos;s\nimplementation of PCI error recovery is imposing restrictions that\nneither powerpc\u0026apos;s EEH nor PCI AER handling need. Tests show that PCI\nerror recovery on s390 is running to completion even without blocking\naccess to PCI config space.(CVE-2025-68310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Prevents free active kevent\n\nThe root cause of this issue are:\n1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);\nput the kevent work in global workqueue. However, the kevent has not yet\nbeen scheduled when the usbnet device is unregistered. Therefore, executing\nfree_netdev() results in the \u0026quot;free active object (kevent)\u0026quot; error reported\nhere.\n\n2. Another factor is that when calling usbnet_disconnect()-\u0026gt;unregister_netdev(),\nif the usbnet device is up, ndo_stop() is executed to cancel the kevent.\nHowever, because the device is not up, ndo_stop() is not executed.\n\nThe solution to this problem is to cancel the kevent before executing\nfree_netdev().(CVE-2025-68312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config unlock in nbd_genl_connect\n\nThere is one use-after-free warning when running NBD_CMD_CONNECT and\nNBD_CLEAR_SOCK:\n\nnbd_genl_connect\n nbd_alloc_and_init_config // config_refs=1\n nbd_start_device // config_refs=2\n set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3\n recv_work done // config_refs=2\n\t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1\n\t\t\t\t\t\tclose nbd // config_refs=0\n refcount_inc -\u0026gt; uaf\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290\n nbd_genl_connect+0x16d0/0x1ab0\n genl_family_rcv_msg_doit+0x1f3/0x310\n genl_rcv_msg+0x44a/0x790\n\nThe issue can be easily reproduced by adding a small delay before\nrefcount_inc(\u0026amp;nbd-\u0026gt;config_refs) in nbd_genl_connect():\n\n mutex_unlock(\u0026amp;nbd-\u0026gt;config_lock);\n if (!ret) {\n set_bit(NBD_RT_HAS_CONFIG_REF, \u0026amp;config-\u0026gt;runtime_flags);\n+ printk(\u0026quot;before sleep\\n\u0026quot;);\n+ mdelay(5 * 1000);\n+ printk(\u0026quot;after sleep\\n\u0026quot;);\n refcount_inc(\u0026amp;nbd-\u0026gt;config_refs);\n nbd_connect_reply(info, nbd-\u0026gt;index);\n }(CVE-2025-68366)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse\n\nThe following warning appears when running syzkaller, and this issue also\nexists in the mainline code.\n\n ------------[ cut here ]------------\n list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.\n WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130\n Modules linked in:\n CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__list_add_valid_or_report+0xf7/0x130\n RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282\n RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817\n RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001\n RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c\n R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100\n R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48\n FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 80000000\n Call Trace:\n \u0026lt;TASK\u0026gt;\n input_register_handler+0xb3/0x210\n mac_hid_start_emulation+0x1c5/0x290\n mac_hid_toggle_emumouse+0x20a/0x240\n proc_sys_call_handler+0x4c2/0x6e0\n new_sync_write+0x1b1/0x2d0\n vfs_write+0x709/0x950\n ksys_write+0x12a/0x250\n do_syscall_64+0x5a/0x110\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe WARNING occurs when two processes concurrently write to the mac-hid\nemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().\nBoth processes read old_val=0, then both try to register the input handler,\nleading to a double list_add of the same handler.\n\n CPU0 CPU1\n ------------------------- -------------------------\n vfs_write() //write 1 vfs_write() //write 1\n proc_sys_write() proc_sys_write()\n mac_hid_toggle_emumouse() mac_hid_toggle_emumouse()\n old_val = *valp // old_val=0\n old_val = *valp // old_val=0\n mutex_lock_killable()\n proc_dointvec() // *valp=1\n mac_hid_start_emulation()\n input_register_handler()\n mutex_unlock()\n mutex_lock_killable()\n proc_dointvec()\n mac_hid_start_emulation()\n input_register_handler() //Trigger Warning\n mutex_unlock()\n\nFix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: smartpqi: Fix device resources accessed after device removal\n\nCorrect possible race conditions during device removal.\n\nPreviously, a scheduled work item to reset a LUN could still execute\nafter the device was removed, leading to use-after-free and other\nresource access issues.\n\nThis race condition occurs because the abort handler may schedule a LUN\nreset concurrently with device removal via sdev_destroy(), leading to\nuse-after-free and improper access to freed resources.\n\n - Check in the device reset handler if the device is still present in\n the controller\u0026apos;s SCSI device list before running; if not, the reset\n is skipped.\n\n - Cancel any pending TMF work that has not started in sdev_destroy().\n\n - Ensure device freeing in sdev_destroy() is done while holding the\n LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config put in recv_work\n\nThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK and\nNBD_CMD_RECONFIGURE:\n nbd_genl_connect // conf_ref=2 (connect and recv_work A)\n nbd_open\t // conf_ref=3\n recv_work A done // conf_ref=2\n NBD_CLEAR_SOCK // conf_ref=1\n nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)\n close nbd\t // conf_ref=1\n recv_work B\n config_put // conf_ref=0\n atomic_dec(\u0026amp;config-\u0026gt;recv_threads); -\u0026gt; UAF\n\nOr only running NBD_CLEAR_SOCK:\n nbd_genl_connect // conf_ref=2\n nbd_open \t // conf_ref=3\n NBD_CLEAR_SOCK // conf_ref=2\n close nbd\n nbd_release\n config_put // conf_ref=1\n recv_work\n config_put \t // conf_ref=0\n atomic_dec(\u0026amp;config-\u0026gt;recv_threads); -\u0026gt; UAF\n\nCommit 87aac3a80af5 (\u0026quot;nbd: call nbd_config_put() before notifying the\nwaiter\u0026quot;) moved nbd_config_put() to run before waking up the waiter in\nrecv_work, in order to ensure that nbd_start_device_ioctl() would not\nbe woken up while nbd-\u0026gt;task_recv was still uncleared.\n\nHowever, in nbd_start_device_ioctl(), after being woken up it explicitly\ncalls flush_workqueue() to make sure all current works are finished.\nTherefore, there is no need to move the config put ahead of the wakeup.\n\nMove nbd_config_put() to the end of recv_work, so that the reference is\nheld for the whole lifetime of the worker thread. This makes sure the\nconfig cannot be freed while recv_work is still running, even if clear\n+ reconfigure interleave.\n\nIn addition, we don\u0026apos;t need to worry about recv_work dropping the last\nnbd_put (which causes deadlock):\n\npath A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):\n connect // nbd_refs=1 (trigger recv_work)\n open nbd // nbd_refs=2\n NBD_CLEAR_SOCK\n close nbd\n nbd_release\n nbd_disconnect_and_put\n flush_workqueue // recv_work done\n nbd_config_put\n nbd_put // nbd_refs=1\n nbd_put // nbd_refs=0\n queue_work\n\npath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):\n connect // nbd_refs=2 (trigger recv_work)\n open nbd // nbd_refs=3\n NBD_CLEAR_SOCK // conf_refs=2\n close nbd\n nbd_release\n nbd_config_put // conf_refs=1\n nbd_put // nbd_refs=2\n recv_work done // conf_refs=0, nbd_refs=1\n rmmod // nbd_refs=0\n\nDepends-on: e2daec488c57 (\u0026quot;nbd: Fix hungtask when nbd_config_put\u0026quot;)(CVE-2025-68372)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix rcu protection in md_wakeup_thread\n\nWe attempted to use RCU to protect the pointer \u0026apos;thread\u0026apos;, but directly\npassed the value when calling md_wakeup_thread(). This means that the\nRCU pointer has been acquired before rcu_read_lock(), which renders\nrcu_read_lock() ineffective and could lead to a use-after-free.(CVE-2025-68374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix null deref on srq-\u0026gt;rq.queue after resize failure\n\nA NULL pointer dereference can occur in rxe_srq_chk_attr() when\nibv_modify_srq() is invoked twice in succession under certain error\nconditions. The first call may fail in rxe_queue_resize(), which leads\nrxe_srq_from_attr() to set srq-\u0026gt;rq.queue = NULL. The second call then\ntriggers a crash (null deref) when accessing\nsrq-\u0026gt;rq.queue-\u0026gt;buf-\u0026gt;index_mask.\n\nCall Trace:\n\u0026lt;TASK\u0026gt;\nrxe_modify_srq+0x170/0x480 [rdma_rxe]\n? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]\n? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]\n? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]\nib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]\n? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]\n? tryinc_node_nr_active+0xe6/0x150\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\nib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]\n? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]\n? __pfx___raw_spin_lock_irqsave+0x10/0x10\n? __pfx_do_vfs_ioctl+0x10/0x10\n? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0\n? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10\nib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]\n? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]\n__x64_sys_ioctl+0x138/0x1c0\ndo_syscall_64+0x82/0x250\n? fdget_pos+0x58/0x4c0\n? ksys_write+0xf3/0x1c0\n? __pfx_ksys_write+0x10/0x10\n? do_syscall_64+0xc8/0x250\n? __pfx_vm_mmap_pgoff+0x10/0x10\n? fget+0x173/0x230\n? fput+0x2a/0x80\n? ksys_mmap_pgoff+0x224/0x4c0\n? do_syscall_64+0xc8/0x250\n? do_user_addr_fault+0x37b/0xfe0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-68379)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags\n\nWhen a filesystem is being automounted, it needs to preserve the\nuser-set superblock mount options, such as the \u0026quot;ro\u0026quot; flag.(CVE-2025-68764)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfsnotify: do not generate ACCESS/MODIFY events on child for special files\n\ninotify/fanotify do not allow users with no read access to a file to\nsubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the\nsame user to subscribe for watching events on children when the user\nhas access to the parent directory (e.g. /dev).\n\nUsers with no read access to a file but with read access to its parent\ndirectory can still stat the file and see if it was accessed/modified\nvia atime/mtime change.\n\nThe same is not true for special files (e.g. /dev/null). Users will not\ngenerally observe atime/mtime changes when other users read/write to\nspecial files, only when someone sets atime/mtime via utimensat().\n\nAlign fsnotify events with this stat behavior and do not generate\nACCESS/MODIFY events to parent watchers on read/write of special files.\nThe events are still generated to parent watchers on utimensat(). This\ncloses some side-channels that could be possibly used for information\nexfiltration [1].\n\n[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: missing copy_finish in fuse-over-io-uring argument copies\n\nFix a possible reference count leak of payload pages during\nfuse argument copies.\n\n[Joanne: simplified error cleanup](CVE-2025-68791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd: Check event before enable to avoid GPF\n\nOn AMD machines cpuc-\u0026gt;events[idx] can become NULL in a subtle race\ncondition with NMI-\u0026gt;throttle-\u0026gt;x86_pmu_stop().\n\nCheck event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.\nThis appears to be an AMD only issue.\n\nSyzkaller reported a GPF in amd_pmu_enable_all.\n\nINFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143\n msecs\nOops: general protection fault, probably for non-canonical address\n 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]\nCPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk\nRIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195\n arch/x86/events/core.c:1430)\nRSP: 0018:ffff888118009d60 EFLAGS: 00010012\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002\nR13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601\nFS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\namd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))\nx86_pmu_enable (arch/x86/events/core.c:1360)\nevent_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186\n kernel/events/core.c:2346)\n__perf_remove_from_context (kernel/events/core.c:2435)\nevent_function (kernel/events/core.c:259)\nremote_function (kernel/events/core.c:92 (discriminator 1)\n kernel/events/core.c:72 (discriminator 1))\n__flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27\n ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64\n kernel/smp.c:135 kernel/smp.c:540)\n__sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27\n ./include/linux/jump_label.h:207\n ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)\nsysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)\n arch/x86/kernel/smp.c:266 (discriminator 47))\n \u0026lt;/IRQ\u0026gt;(CVE-2025-68798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats\n\nCited commit added a dedicated mutex (instead of RTNL) to protect the\nmulticast route list, so that it will not change while the driver\nperiodically traverses it in order to update the kernel about multicast\nroute stats that were queried from the device.\n\nOne instance of list entry deletion (during route replace) was missed\nand it can result in a use-after-free [1].\n\nFix by acquiring the mutex before deleting the entry from the list and\nreleasing it afterwards.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]\nRead of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043\n\nCPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)\nHardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017\nWorkqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xba/0x110\n print_report+0x174/0x4f5\n kasan_report+0xdf/0x110\n mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 29933:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]\n mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30\n\nFreed by task 29933:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x70\n __kasan_slab_free+0x43/0x70\n kfree+0x14e/0x700\n mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]\n mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30(CVE-2025-68800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix neighbour use-after-free\n\nWe sometimes observe use-after-free when dereferencing a neighbour [1].\nThe problem seems to be that the driver stores a pointer to the\nneighbour, but without holding a reference on it. A reference is only\ntaken when the neighbour is used by a nexthop.\n\nFix by simplifying the reference counting scheme. Always take a\nreference when storing a neighbour pointer in a neighbour entry. Avoid\ntaking a referencing when the neighbour is used by a nexthop as the\nneighbour entry associated with the nexthop already holds a reference.\n\nTested by running the test that uncovered the problem over 300 times.\nWithout this patch the problem was reproduced after a handful of\niterations.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310\nRead of size 8 at addr ffff88817f8e3420 by task ip/3929\n\nCPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6e/0x300\n print_report+0xfc/0x1fb\n kasan_report+0xe4/0x110\n mlxsw_sp_neigh_entry_update+0x2d4/0x310\n mlxsw_sp_router_rif_gone_sync+0x35f/0x510\n mlxsw_sp_rif_destroy+0x1ea/0x730\n mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0\n __mlxsw_sp_inetaddr_lag_event+0xcc/0x130\n __mlxsw_sp_inetaddr_event+0xf5/0x3c0\n mlxsw_sp_router_netdevice_event+0x1015/0x1580\n notifier_call_chain+0xcc/0x150\n call_netdevice_notifiers_info+0x7e/0x100\n __netdev_upper_dev_unlink+0x10b/0x210\n netdev_upper_dev_unlink+0x79/0xa0\n vrf_del_slave+0x18/0x50\n do_set_master+0x146/0x7d0\n do_setlink.isra.0+0x9a0/0x2880\n rtnl_newlink+0x637/0xb20\n rtnetlink_rcv_msg+0x6fe/0xb90\n netlink_rcv_skb+0x123/0x380\n netlink_unicast+0x4a3/0x770\n netlink_sendmsg+0x75b/0xc90\n __sock_sendmsg+0xbe/0x160\n ____sys_sendmsg+0x5b2/0x7d0\n ___sys_sendmsg+0xfd/0x180\n __sys_sendmsg+0x124/0x1c0\n do_syscall_64+0xbb/0xfd0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[...]\n\nAllocated by task 109:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x2c1/0x790\n neigh_alloc+0x6af/0x8f0\n ___neigh_create+0x63/0xe90\n mlxsw_sp_nexthop_neigh_init+0x430/0x7e0\n mlxsw_sp_nexthop_type_init+0x212/0x960\n mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280\n mlxsw_sp_nexthop6_group_get+0x392/0x6a0\n mlxsw_sp_fib6_entry_create+0x46a/0xfd0\n mlxsw_sp_router_fib6_replace+0x1ed/0x5f0\n mlxsw_sp_router_fib6_event_work+0x10a/0x2a0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nFreed by task 154:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x43/0x70\n kmem_cache_free_bulk.part.0+0x1eb/0x5e0\n kvfree_rcu_bulk+0x1f2/0x260\n kfree_rcu_work+0x130/0x1b0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nLast potentially related work creation:\n kasan_save_stack+0x30/0x50\n kasan_record_aux_stack+0x8c/0xa0\n kvfree_call_rcu+0x93/0x5b0\n mlxsw_sp_router_neigh_event_work+0x67d/0x860\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20(CVE-2025-68801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix io-uring list corruption for terminated non-committed requests\n\nWhen a request is terminated before it has been committed, the request\nis not removed from the queue\u0026apos;s list. This leaves a dangling list entry\nthat leads to list corruption and use-after-free issues.\n\nRemove the request from the queue\u0026apos;s list for terminated non-committed\nrequests.(CVE-2025-68805)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix readahead reclaim deadlock\n\nCommit e26ee4efbc79 (\u0026quot;fuse: allocate ff-\u0026gt;release_args only if release is\nneeded\u0026quot;) skips allocating ff-\u0026gt;release_args if the server does not\nimplement open. However in doing so, fuse_prepare_release() now skips\ngrabbing the reference on the inode, which makes it possible for an\ninode to be evicted from the dcache while there are inflight readahead\nrequests. This causes a deadlock if the server triggers reclaim while\nservicing the readahead request and reclaim attempts to evict the inode\nof the file being read ahead. Since the folio is locked during\nreadahead, when reclaim evicts the fuse inode and fuse_evict_inode()\nattempts to remove all folios associated with the inode from the page\ncache (truncate_inode_pages_range()), reclaim will block forever waiting\nfor the lock since readahead cannot relinquish the lock because it is\nitself blocked in reclaim:\n\n\u0026gt;\u0026gt;\u0026gt; stack_trace(1504735)\n folio_wait_bit_common (mm/filemap.c:1308:4)\n folio_lock (./include/linux/pagemap.h:1052:3)\n truncate_inode_pages_range (mm/truncate.c:336:10)\n fuse_evict_inode (fs/fuse/inode.c:161:2)\n evict (fs/inode.c:704:3)\n dentry_unlink_inode (fs/dcache.c:412:3)\n __dentry_kill (fs/dcache.c:615:3)\n shrink_kill (fs/dcache.c:1060:12)\n shrink_dentry_list (fs/dcache.c:1087:3)\n prune_dcache_sb (fs/dcache.c:1168:2)\n super_cache_scan (fs/super.c:221:10)\n do_shrink_slab (mm/shrinker.c:435:9)\n shrink_slab (mm/shrinker.c:626:10)\n shrink_node (mm/vmscan.c:5951:2)\n shrink_zones (mm/vmscan.c:6195:3)\n do_try_to_free_pages (mm/vmscan.c:6257:3)\n do_swap_page (mm/memory.c:4136:11)\n handle_pte_fault (mm/memory.c:5562:10)\n handle_mm_fault (mm/memory.c:5870:9)\n do_user_addr_fault (arch/x86/mm/fault.c:1338:10)\n handle_page_fault (arch/x86/mm/fault.c:1481:3)\n exc_page_fault (arch/x86/mm/fault.c:1539:2)\n asm_exc_page_fault+0x22/0x27\n\nFix this deadlock by allocating ff-\u0026gt;release_args and grabbing the\nreference on the inode when preparing the file for release even if the\nserver does not implement open. The inode reference will be dropped when\nthe last reference on the fuse file is dropped (see fuse_file_put() -\u0026gt;\nfuse_release_end()).(CVE-2025-68821)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\u0026quot;i40evf: Allow PF driver to configure RSS\u0026quot;),\nthe loop upper bounds were:\n i \u0026lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u0026lt;= adapter-\u0026gt;rss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u0026lt;=`\naccesses one element past the end.\n\nFix the issues by using `\u0026lt;` instead of `\u0026lt;=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u0026gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000: fix OOB in e1000_tbi_should_accept()\n\nIn e1000_tbi_should_accept() we read the last byte of the frame via\n\u0026apos;data[length - 1]\u0026apos; to evaluate the TBI workaround. If the descriptor-\nreported length is zero or larger than the actual RX buffer size, this\nread goes out of bounds and can hit unrelated slab objects. The issue\nis observed from the NAPI receive path (e1000_clean_rx_irq):\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790\nRead of size 1 at addr ffff888014114e54 by task sshd/363\n\nCPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x5a/0x74\n print_address_description+0x7b/0x440\n print_report+0x101/0x200\n kasan_report+0xc1/0xf0\n e1000_tbi_should_accept+0x610/0x790\n e1000_clean_rx_irq+0xa8c/0x1110\n e1000_clean+0xde2/0x3c10\n __napi_poll+0x98/0x380\n net_rx_action+0x491/0xa20\n __do_softirq+0x2c9/0x61d\n do_softirq+0xd1/0x120\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0xfe/0x130\n ip_finish_output2+0x7d5/0xb00\n __ip_queue_xmit+0xe24/0x1ab0\n __tcp_transmit_skb+0x1bcb/0x3340\n tcp_write_xmit+0x175d/0x6bd0\n __tcp_push_pending_frames+0x7b/0x280\n tcp_sendmsg_locked+0x2e4f/0x32d0\n tcp_sendmsg+0x24/0x40\n sock_write_iter+0x322/0x430\n vfs_write+0x56c/0xa60\n ksys_write+0xd1/0x190\n do_syscall_64+0x43/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f511b476b10\nCode: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24\nRSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10\nRDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003\nRBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00\nR10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003\n \u0026lt;/TASK\u0026gt;\nAllocated by task 1:\n __kasan_krealloc+0x131/0x1c0\n krealloc+0x90/0xc0\n add_sysfs_param+0xcb/0x8a0\n kernel_add_sysfs_param+0x81/0xd4\n param_sysfs_builtin+0x138/0x1a6\n param_sysfs_init+0x57/0x5b\n do_one_initcall+0x104/0x250\n do_initcall_level+0x102/0x132\n do_initcalls+0x46/0x74\n kernel_init_freeable+0x28f/0x393\n kernel_init+0x14/0x1a0\n ret_from_fork+0x22/0x30\nThe buggy address belongs to the object at ffff888014114000\n which belongs to the cache kmalloc-2k of size 2048\nThe buggy address is located 1620 bytes to the right of\n 2048-byte region [ffff888014114000, ffff888014114800]\nThe buggy address belongs to the physical page:\npage:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110\nhead:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0\nflags: 0x100000000010200(slab|head|node=0|zone=1)\nraw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000\nraw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n==================================================================\n\nThis happens because the TBI check unconditionally dereferences the last\nbyte without validating the reported length first:\n\n\tu8 last_byte = *(data + length - 1);\n\nFix by rejecting the frame early if the length is zero, or if it exceeds\nadapter-\u0026gt;rx_buffer_len. This preserves the TBI workaround semantics for\nvalid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: Handle incorrect num_connectors capability\n\nThe UCSI spec states that the num_connectors field is 7 bits, and the\n8th bit is reserved and should be set to zero.\nSome buggy FW has been known to set this bit, and it can lead to a\nsystem not booting.\nFlag that the FW is not behaving correctly, and auto-fix the value\nso that the system boots correctly.\n\nFound on Lenovo P1 G8 during Linux enablement program. The FW will\nbe fixed, but seemed worth addressing in case it hit platforms that\naren\u0026apos;t officially Linux supported.(CVE-2025-71108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - zero initialize memory allocated via sock_kmalloc\n\nSeveral crypto user API contexts and requests allocated with\nsock_kmalloc() were left uninitialized, relying on callers to\nset fields explicitly. This resulted in the use of uninitialized\ndata in certain error paths or when new fields are added in the\nfuture.\n\nThe ACVP patches also contain two user-space interface files:\nalgif_kpp.c and algif_akcipher.c. These too rely on proper\ninitialization of their context structures.\n\nA particular issue has been observed with the newly added\n\u0026apos;inflight\u0026apos; variable introduced in af_alg_ctx by commit:\n\n 67b164a871af (\u0026quot;crypto: af_alg - Disallow multiple in-flight AIO requests\u0026quot;)\n\nBecause the context is not memset to zero after allocation,\nthe inflight variable has contained garbage values. As a result,\naf_alg_alloc_areq() has incorrectly returned -EBUSY randomly when\nthe garbage value was interpreted as true:\n\n https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209\n\nThe check directly tests ctx-\u0026gt;inflight without explicitly\ncomparing against true/false. Since inflight is only ever set to\ntrue or false later, an uninitialized value has triggered\n-EBUSY failures. Zero-initializing memory allocated with\nsock_kmalloc() ensures inflight and other fields start in a known\nstate, removing random issues caused by uninitialized data.(CVE-2025-71113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/kexec: Enable SMT before waking offline CPUs\n\nIf SMT is disabled or a partial SMT state is enabled, when a new kernel\nimage is loaded for kexec, on reboot the following warning is observed:\n\nkexec: Waking offline cpu 228.\nWARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc\n[snip]\n NIP kexec_prepare_cpus+0x1b0/0x1bc\n LR kexec_prepare_cpus+0x1a0/0x1bc\n Call Trace:\n kexec_prepare_cpus+0x1a0/0x1bc (unreliable)\n default_machine_kexec+0x160/0x19c\n machine_kexec+0x80/0x88\n kernel_kexec+0xd0/0x118\n __do_sys_reboot+0x210/0x2c4\n system_call_exception+0x124/0x320\n system_call_vectored_common+0x15c/0x2ec\n\nThis occurs as add_cpu() fails due to cpu_bootable() returning false for\nCPUs that fail the cpu_smt_thread_allowed() check or non primary\nthreads if SMT is disabled.\n\nFix the issue by enabling SMT and resetting the number of SMT threads to\nthe number of threads per core, before attempting to wake up all present\nCPUs.(CVE-2025-71119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not register unsupported perf events\n\nSynthetic events currently do not have a function to register perf events.\nThis leads to calling the tracepoint register functions with a NULL\nfunction pointer which triggers:\n\n ------------[ cut here ]------------\n WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:tracepoint_add_func+0x357/0x370\n Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc \u0026lt;0f\u0026gt; 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f\n RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246\n RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000\n RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8\n RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780\n R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a\n R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78\n FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register+0x5d/0x90\n synth_event_reg+0x3c/0x60\n perf_trace_event_init+0x204/0x340\n perf_trace_init+0x85/0xd0\n perf_tp_event_init+0x2e/0x50\n perf_try_init_event+0x6f/0x230\n ? perf_event_alloc+0x4bb/0xdc0\n perf_event_alloc+0x65a/0xdc0\n __se_sys_perf_event_open+0x290/0x9f0\n do_syscall_64+0x93/0x7b0\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? trace_hardirqs_off+0x53/0xc0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInstead, have the code return -ENODEV, which doesn\u0026apos;t warn and has perf\nerror out with:\n\n # perf record -e synthetic:futex_wait\nError:\nThe sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).\n\u0026quot;dmesg | grep -i perf\u0026quot; may provide additional information.\n\nIdeally perf should support synthetic events, but for now just fix the\nwarning. The support can come later.(CVE-2025-71125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix memory and information leak in smb3_reconfigure()\n\nIn smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the\nfunction returns immediately without freeing and erasing the newly\nallocated new_password and new_password2. This causes both a memory leak\nand a potential information leak.\n\nFix this by calling kfree_sensitive() on both password buffers before\nreturning in this error case.(CVE-2025-71151)",
"id": "OESA-2026-1304",
"modified": "2026-08-06T11:10:20Z",
"published": "2026-02-06T11:10:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38110"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38162"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38208"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38303"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38712"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39721"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40252"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40264"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40268"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40311"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40314"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40328"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40345"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40360"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40363"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68185"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68191"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68218"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68219"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68251"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68295"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68296"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68367"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68371"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68372"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68374"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68379"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68764"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68788"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71113"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71151"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-57994",
"CVE-2024-58012",
"CVE-2025-37800",
"CVE-2025-38110",
"CVE-2025-38111",
"CVE-2025-38149",
"CVE-2025-38162",
"CVE-2025-38208",
"CVE-2025-38232",
"CVE-2025-38244",
"CVE-2025-38303",
"CVE-2025-38342",
"CVE-2025-38393",
"CVE-2025-38455",
"CVE-2025-38489",
"CVE-2025-38676",
"CVE-2025-38688",
"CVE-2025-38697",
"CVE-2025-38712",
"CVE-2025-38713",
"CVE-2025-38714",
"CVE-2025-38728",
"CVE-2025-39720",
"CVE-2025-39721",
"CVE-2025-39730",
"CVE-2025-39737",
"CVE-2025-39749",
"CVE-2025-39798",
"CVE-2025-39823",
"CVE-2025-39828",
"CVE-2025-39838",
"CVE-2025-39839",
"CVE-2025-39927",
"CVE-2025-39929",
"CVE-2025-39951",
"CVE-2025-40083",
"CVE-2025-40087",
"CVE-2025-40099",
"CVE-2025-40103",
"CVE-2025-40105",
"CVE-2025-40111",
"CVE-2025-40250",
"CVE-2025-40252",
"CVE-2025-40259",
"CVE-2025-40261",
"CVE-2025-40264",
"CVE-2025-40268",
"CVE-2025-40273",
"CVE-2025-40284",
"CVE-2025-40304",
"CVE-2025-40311",
"CVE-2025-40314",
"CVE-2025-40319",
"CVE-2025-40320",
"CVE-2025-40322",
"CVE-2025-40324",
"CVE-2025-40328",
"CVE-2025-40345",
"CVE-2025-40350",
"CVE-2025-40360",
"CVE-2025-40363",
"CVE-2025-68178",
"CVE-2025-68184",
"CVE-2025-68185",
"CVE-2025-68191",
"CVE-2025-68218",
"CVE-2025-68219",
"CVE-2025-68229",
"CVE-2025-68239",
"CVE-2025-68241",
"CVE-2025-68245",
"CVE-2025-68251",
"CVE-2025-68288",
"CVE-2025-68295",
"CVE-2025-68296",
"CVE-2025-68305",
"CVE-2025-68310",
"CVE-2025-68312",
"CVE-2025-68366",
"CVE-2025-68367",
"CVE-2025-68371",
"CVE-2025-68372",
"CVE-2025-68374",
"CVE-2025-68379",
"CVE-2025-68764",
"CVE-2025-68788",
"CVE-2025-68791",
"CVE-2025-68798",
"CVE-2025-68800",
"CVE-2025-68801",
"CVE-2025-68805",
"CVE-2025-68821",
"CVE-2025-71087",
"CVE-2025-71093",
"CVE-2025-71108",
"CVE-2025-71113",
"CVE-2025-71119",
"CVE-2025-71125",
"CVE-2025-71151"
]
}
OESA-2026-1305 (CVE-2024-57994)
Vulnerability from osv_openeuler – Published: 2026-02-06 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()
Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.
syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]
As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.
Rename helpers to better reflect they are safe against BH only.
- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
- skb_array_resize_multiple() to skb_array_resize_multiple_bh()
[1]
WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tun_ptr_free drivers/net/tun.c:617 [inline] __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline] ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline] tun_queue_resize drivers/net/tun.c:3694 [inline] tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550(CVE-2024-57994)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params
Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.(CVE-2024-58012)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential NULL pointer dereference in dev_uevent()
If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it.
Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing.(CVE-2025-37800)
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds clause 45 read/write access
When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.
Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38110)
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds read/write access
When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.
Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38111)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: clear phydev->devlink when the link is deleted
There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows.
[ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34
Therefore, phydev->devlink needs to be cleared when the device link is deleted.(CVE-2025-38149)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: prevent overflow in lookup table allocation
When calculating the lookup table size, ensure the following multiplication does not overflow:
- desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.
- NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.
- sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field.
Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this.
While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().(CVE-2025-38162)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: add NULL check in automount_fullpath
page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: fix race between nfsd registration and exports_proc
As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd.
Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd
for 5.4 kernel ARM64:
CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0
CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
PC is at : exports_net_open+0x50/0x68 [nfsd]
Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248
Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().
and same is happening on latest 6.14 kernel as well:
[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]---
It reproduced simply with below script: while [ 1 ] do /exportfs -r done &
while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done &
So exporting interfaces to user space shall be done at last and cleanup at first place.
With change there is no Kernel OOPs.(CVE-2025-38232)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential deadlock when reconnecting channels
Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening
====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W
cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200
but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30
other info that might help us debug this:
Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock);
*** DEADLOCK ***
3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200(CVE-2025-38244)
In the Linux kernel, the following vulnerability has been resolved:
software node: Correct a OOB check in software_node_get_reference_args()
software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property.
Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN
We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero.
It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.(CVE-2025-38393)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight
Reject migration of SEV{-ES} state if either the source or destination VM is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the section between incrementing created_vcpus and online_vcpus. The bulk of vCPU creation runs outside of kvm->lock to allow creating multiple vCPUs in parallel, and so sev_info.es_active can get toggled from false=>true in the destination VM after (or during) svm_vcpu_create(), resulting in an SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.
The issue manifests most visibly as a crash when trying to free a vCPU's NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.
BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:freepages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 </TASK> Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]---
Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated---(CVE-2025-38455)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Abort __tc_modify_qdisc if parent class does not exist
Lion's patch [1] revealed an ancient bug in the qdisc API. Whenever a user creates/modifies a qdisc specifying as a parent another qdisc, the qdisc API will, during grafting, detect that the user is not trying to attach to a class and reject. However grafting is performed after qdisc_create (and thus the qdiscs' init callback) is executed. In qdiscs that eventually call qdisc_tree_reduce_backlog during init or change (such as fq, hhf, choke, etc), an issue arises. For example, executing the following commands:
sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq
Qdiscs such as fq, hhf, choke, etc unconditionally invoke qdisc_tree_reduce_backlog() in their control path init() or change() which then causes a failure to find the child class; however, that does not stop the unconditional invocation of the assumed child qdisc's qlen_notify with a null class. All these qdiscs make the assumption that class is non-null.
The solution is ensure that qdisc_leaf() which looks up the parent class, and is invoked prior to qdisc_create(), should return failure on not finding the class. In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the parentid doesn't correspond to a class, so that we can detect it earlier on and abort before qdisc_create is called.
[1] https://lore.kernel.org/netdev/(CVE-2025-38457)
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Prevent ALIGN() overflow
When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova.
Open code the ALIGN() using get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either.
Consolidate the two copies of this code under a single helper.
This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range.(CVE-2025-38688)
In the Linux kernel, the following vulnerability has been resolved:
jfs: upper bound check of tree index in dbAllocAG
When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.(CVE-2025-38697)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplus_fill_super() assumes that the attributes file is not yet created, which later results in hitting BUG_ON() when hfsplus_create_attributes_file() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc():
[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfxx64sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---(CVE-2025-38713)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
The hfsplus_bnode_read() method can trigger the issue:
[ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] <TASK> [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0 [ 174.854305][ T9784] print_report+0xd0/0x660 [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610 [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854337][ T9784] kasan_report+0xc6/0x100 [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360 [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380 [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10 [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0 [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310 [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0 [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0 [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10 [ 174.854427][ T9784] ? __pfxhfsplusdelete_attr+0x10/0x10 [ 174.854436][ T9784] ? asan_memset+0x23/0x50 [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320 [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10 [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0 [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0 [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10 [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10 [ 174.854525][ T9784] ? down_write+0x148/0x200 [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10 [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0 [ 174.854549][ T9784] do_unlinkat+0x490/0x670 [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10 [ 174.854565][ T9784] ? __might_fault+0xbc/0x130 [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550 [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110 [ 174.854592][ T9784] do_syscall_64+0xc9/0x480 [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] </TASK> [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasan_save_stack+0x20/0x40 [ 174.880082][ T9784] kasan_save_track+0x14/0x30 [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0 [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550 [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890 [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10 [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520 [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3 ---truncated---(CVE-2025-38714)
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix for slab out of bounds on mount to ksmbd
With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below):
BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827
CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 cifs
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix refcount leak causing resource not released
When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.(CVE-2025-39720)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()
The function needs to check the minimal filehandle length before it can access the embedded filehandle.(CVE-2025-39730)
In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()
A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.
watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]
The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.
The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects.
As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.(CVE-2025-39737)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix the setting of capabilities when automounting a new filesystem
Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again.(CVE-2025-39798)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: use array_index_nospec with indices that come from guest
min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.(CVE-2025-39823)
In the Linux kernel, the following vulnerability has been resolved:
atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().
syzbot reported the splat below. [0]
When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.
The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.
The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.
struct atmtcp_control { struct atmtcp_hdr hdr; / must be first / ... atm_kptr_t vcc; / both directions / ... } __ATM_API_ALIGN;
typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;
The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().
atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:
- .ndo_start_xmit() (vcc->send() == atm_send_aal0())
- vcc_sendmsg()
The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.
Let's add a new ->pre_send() hook to validate messages from sendmsg().
[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 _syssendmsg+0x505/0x830 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in:(CVE-2025-39828)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix OOB read/write in network-coding decode
batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.
Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.(CVE-2025-39839)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix race condition validating r_parent before applying state
Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes.
[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated:
When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ](CVE-2025-39927)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path
During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()(CVE-2025-39929)
In the Linux kernel, the following vulnerability has been resolved:
um: virtio_uml: Fix use-after-free after put_device in probe
When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.(CVE-2025-39951)
In the Linux kernel, the following vulnerability has been resolved:
media: tuner: xc5000: Fix use-after-free in xc5000_release
The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv.
A typical race condition is illustrated below:
CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated.
A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here.
This bug was initially identified through static analysis.
hverkuil: fix typo in Subject: tunner -> tuner
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Disallow dirty tracking if incoherent page walk
Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work.
The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:
"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault."
To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported.(CVE-2025-40058)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Define a proc_layoutcommit for the FlexFiles layout type
Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.(CVE-2025-40087)
In the Linux kernel, the following vulnerability has been resolved:
cifs: parse_dfs_referrals: prevent oob on malformed input
Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS
- reply smaller than sizeof(struct get_dfs_referral_rsp)
- reply with number of referrals smaller than NumberOfReferrals in the header
Processing of such replies will cause oob.
Return -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix refcount leak for cifs_sb_tlink
Fix three refcount inconsistency issues related to cifs_sb_tlink.
Comments for cifs_sb_tlink state that cifs_put_tlink() needs to be
called after successful calls to cifs_sb_tlink(). Three calls fail to
update refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix Use-after-free in validation
Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.(CVE-2025-40111)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Clean up only new IRQ glue on request_irq() failure
The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added.
This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object.
Note: This error is observed when both fwctl and rds configs are enabled.
[1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI
RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: <TASK> ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a _syssendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b _sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---(CVE-2025-40250)
In the Linux kernel, the following vulnerability has been resolved:
net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()
The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array.
Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40252)
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Do not sleep in atomic context
sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.(CVE-2025-40259)
In the Linux kernel, the following vulnerability has been resolved:
nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()
nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur:
[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] </TASK>(CVE-2025-40261)
In the Linux kernel, the following vulnerability has been resolved:
be2net: pass wrb_params in case of OS2BMC
be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states.
The correct way would be to pass the wrb_params from be_xmit().(CVE-2025-40264)
In the Linux kernel, the following vulnerability has been resolved:
cifs: client: fix memory leak in smb3_fs_context_parse_param
The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation.
To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing.
syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444
BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: free copynotify stateid in nfs4_free_ol_stateid()
Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period.
However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred
WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]
This patch, instead, frees the associated copynotify stateid here.
If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later.
[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: cancel mesh send timer when hdev removed
mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone.
Cancel the timer when MGMT removes the hdev, like other MGMT timers.
Should fix the BUG: sporadically seen by BlueZ test bot (in "Mesh - Send cancel - 1" test).
Log:
BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------(CVE-2025-40284)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches.
Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)
In the Linux kernel, the following vulnerability has been resolved:
accel/habanalabs: support mapping cb with vmalloc-backed coherent memory
When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction.
Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.(CVE-2025-40311)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget
In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free.
Fix: By separating the usb_del_gadget_udc() operation into distinct "del" and "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget().
A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").(CVE-2025-40314)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Sync pending IRQ work before freeing ring buffer
Fix a race where irq_work can be queued in bpf_ringbuf_commit()
but the ring buffer is freed before the work executes.
In the syzbot reproducer, a BPF program attached to sched_switch
triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer
is freed before this work executes, the irq_work thread may accesses
freed memory.
Calling irq_work_sync(&rb->work) ensures that all pending irq_work
complete before freeing the buffer.(CVE-2025-40319)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential cfid UAF in smb2_query_info_compound
When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free.
Reinitialize cfid to NULL under the replay label.
Example trace (trimmed):
refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: <TASK> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80(CVE-2025-40320)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: bitblit: bound-check glyph index in bit_putcs*
bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address.
This fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix crash in nfsd4_read_release()
When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.(CVE-2025-40324)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_close_cached_fid()
find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free.
Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.(CVE-2025-40328)
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: sddr55: Reject out-of-bound new_pba
Discovered by Atuin - Automated Vulnerability Discovery Engine.
new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory.
Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ
XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run.
Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it.
To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.(CVE-2025-40350)
In the Linux kernel, the following vulnerability has been resolved:
drm/sysfb: Do not dereference NULL pointer in plane reset
The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL.
v2: - fix typo in commit description (Javier)(CVE-2025-40360)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix field-spanning memcpy warning in AH output
Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields.
memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439
The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.(CVE-2025-40363)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix possible deadlock while configuring policy
Following deadlock can be triggered easily by lockdep:
WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted
check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180
but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30
-> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
other info that might help us debug this:
Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock);
Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context.
The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.(CVE-2025-68178)
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Disable AFBC support on Mediatek DRM driver
Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier.
However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0.
Kernel trace reports vblank timeouts constantly, and the render is garbled:
[CRTC:62:crtc-0] vblank wait timed out
WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
[...]
Hardware name: MediaTek Genio-700 EVK (DT)
Workqueue: events_unbound commit_work
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
sp : ffff80008337bca0
x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000
x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000
x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80
x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a
x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000
x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b
x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70
x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70
x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480
Call trace:
drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)
drm_atomic_helper_commit_tail_rpm+0x64/0x80
commit_tail+0xa4/0x1a4
commit_work+0x14/0x20
process_one_work+0x150/0x290
worker_thread+0x2d0/0x3ec
kthread+0x12c/0x210
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.(CVE-2025-68184)
In the Linux kernel, the following vulnerability has been resolved:
nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack.
Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.(CVE-2025-68185)
In the Linux kernel, the following vulnerability has been resolved:
udp_tunnel: use netdev_warn() instead of netdev_WARN()
netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug.
udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug.
Replace netdev_WARN() with netdev_warn() accordingly.(CVE-2025-68191)
In the Linux kernel, the following vulnerability has been resolved:
nvme-multipath: fix lockdep WARN due to partition scan work
Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion.
To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.(CVE-2025-68218)
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix memory leak in smb3_fs_context_parse_param error path
Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues.
This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed.
The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak.
This issue was not addressed by commit e8c73eb7db0a ("cifs: client: fix memory leak in smb3_fs_context_parse_param"), which only fixed leaks from repeated fsconfig() calls but not this error path.
Patch updated with minor change suggested by kernel test robot(CVE-2025-68219)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.
Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...(CVE-2025-68229)
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: restore write access before closing files opened by open_exec()
bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed.
However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail.
Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.(CVE-2025-68239)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random.
The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked.
CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]
This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device:
unregister_netdevice: waiting for sitX to become free. Usage count = N
Ido Schimmel provided the simple test validation method [1].
The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed.
[1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1(CVE-2025-68241)
In the Linux kernel, the following vulnerability has been resolved:
net: netpoll: fix incorrect refcount handling causing incorrect cleanup
commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks.
Scenario causing lack of proper cleanup:
1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.
2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.
3) When the first netpolls goes to clean up:
- The first cleanup succeeds and clears np->dev->npinfo, ignoring
refcnt.
- It basically calls RCU_INIT_POINTER(np->dev->npinfo, NULL);
- Set dev->npinfo = NULL, without proper cleanup
- No ->ndo_netpoll_cleanup() is either called
4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.
Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.(CVE-2025-68245)
In the Linux kernel, the following vulnerability has been resolved:
erofs: avoid infinite loops due to corrupted subpage compact indexes
Robert reported an infinite loop observed by two crafted images.
The root cause is that clusterofs can be larger than lclustersize
for !NONHEAD lclusters in corrupted subpage compact indexes, e.g.:
blocksize = lclustersize = 512 lcn = 6 clusterofs = 515
Move the corresponding check for full compress indexes to
z_erofs_load_lcluster_from_disk() to also cover subpage compact
compress indexes.
It also fixes the position of m->type >= Z_EROFS_LCLUSTER_TYPE_MAX
check, since it should be placed right after
z_erofs_load_{compact,full}_lcluster().(CVE-2025-68251)
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase.
Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.(CVE-2025-68288)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix memory leak in cifs_construct_tcon()
When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon().
This fixes the following memory leak reported by kmemleak:
mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-68295)
In the Linux kernel, the following vulnerability has been resolved:
drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup
Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs.
VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array.
Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly.
Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all().
Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.(CVE-2025-68296)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sock: Prevent race in socket write iter and sock bind
There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1].
Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1].
[1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195
Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195
Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)
In the Linux kernel, the following vulnerability has been resolved:
s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump
Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do.
During error recovery testing a pair of tasks was reported to be hung:
mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]
No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too:
- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()
- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.
A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/<BDF> reporter fw_fatal
while PCI error recovery is executed on the same <BDF> physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw <BDF>
Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with "kernel answers: Permission denied" - and we get a kernel log message of:
mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5
because the config read of VSC_SEMAPHORE is rejected by the underlying hardware.
Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.(CVE-2025-68310)
In the Linux kernel, the following vulnerability has been resolved:
usbnet: Prevents free active kevent
The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here.
- Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed.
The solution to this problem is to cancel the kevent before executing free_netdev().(CVE-2025-68312)
In the Linux kernel, the following vulnerability has been resolved:
nbd: defer config unlock in nbd_genl_connect
There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK:
nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf
------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790
The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect():
mutex_unlock(&nbd->config_lock);
if (!ret) {
set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);
- printk("before sleep\n");
- mdelay(5 * 1000);
- printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }(CVE-2025-68366)
In the Linux kernel, the following vulnerability has been resolved:
macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse
The following warning appears when running syzkaller, and this issue also exists in the mainline code.
------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2
The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler.
CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = valp // old_val=0 old_val = valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()
Fix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)
In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Fix device resources accessed after device removal
Correct possible race conditions during device removal.
Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.
This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources.
-
Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.
-
Cancel any pending TMF work that has not started in sdev_destroy().
-
Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)
In the Linux kernel, the following vulnerability has been resolved:
nbd: defer config put in recv_work
There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF
Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF
Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the waiter") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared.
However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup.
Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave.
In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock):
path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work
path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0
Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")(CVE-2025-68372)
In the Linux kernel, the following vulnerability has been resolved:
md: fix rcu protection in md_wakeup_thread
We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.(CVE-2025-68374)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix null deref on srq->rq.queue after resize failure
A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask.
Call Trace: <TASK> rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfxrawspin_lock_irqsave+0x10/0x10 ? pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-68379)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags
When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.(CVE-2025-68764)
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: do not generate ACCESS/MODIFY events on child for special files
inotify/fanotify do not allow users with no read access to a file to subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the same user to subscribe for watching events on children when the user has access to the parent directory (e.g. /dev).
Users with no read access to a file but with read access to its parent directory can still stat the file and see if it was accessed/modified via atime/mtime change.
The same is not true for special files (e.g. /dev/null). Users will not generally observe atime/mtime changes when other users read/write to special files, only when someone sets atime/mtime via utimensat().
Align fsnotify events with this stat behavior and do not generate ACCESS/MODIFY events to parent watchers on read/write of special files. The events are still generated to parent watchers on utimensat(). This closes some side-channels that could be possibly used for information exfiltration [1].
[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)
In the Linux kernel, the following vulnerability has been resolved:
fuse: missing copy_finish in fuse-over-io-uring argument copies
Fix a possible reference count leak of payload pages during fuse argument copies.
Joanne: simplified error cleanup
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd: Check event before enable to avoid GPF
On AMD machines cpuc->events[idx] can become NULL in a subtle race condition with NMI->throttle->x86_pmu_stop().
Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF. This appears to be an AMD only issue.
Syzkaller reported a GPF in amd_pmu_enable_all.
INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143 msecs Oops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7] CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430) RSP: 0018:ffff888118009d60 EFLAGS: 00010012 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601 FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0 Call Trace: <IRQ> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2)) x86_pmu_enable (arch/x86/events/core.c:1360) event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346) __perf_remove_from_context (kernel/events/core.c:2435) event_function (kernel/events/core.c:259) remote_function (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1)) __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540) __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272) sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47)) </IRQ>(CVE-2025-68798)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats
Cited commit added a dedicated mutex (instead of RTNL) to protect the multicast route list, so that it will not change while the driver periodically traverses it in order to update the kernel about multicast route stats that were queried from the device.
One instance of list entry deletion (during route replace) was missed and it can result in a use-after-free [1].
Fix by acquiring the mutex before deleting the entry from the list and releasing it afterwards.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043
CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum] Call Trace: <TASK> dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30
Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30(CVE-2025-68800)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix neighbour use-after-free
We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.
Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.
Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929
CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 _syssendmsg+0x5b2/0x7d0 _sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [...]
Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20(CVE-2025-68801)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix io-uring list corruption for terminated non-committed requests
When a request is terminated before it has been committed, the request is not removed from the queue's list. This leaves a dangling list entry that leads to list corruption and use-after-free issues.
Remove the request from the queue's list for terminated non-committed requests.(CVE-2025-68805)
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix readahead reclaim deadlock
Commit e26ee4efbc79 ("fuse: allocate ff->release_args only if release is needed") skips allocating ff->release_args if the server does not implement open. However in doing so, fuse_prepare_release() now skips grabbing the reference on the inode, which makes it possible for an inode to be evicted from the dcache while there are inflight readahead requests. This causes a deadlock if the server triggers reclaim while servicing the readahead request and reclaim attempts to evict the inode of the file being read ahead. Since the folio is locked during readahead, when reclaim evicts the fuse inode and fuse_evict_inode() attempts to remove all folios associated with the inode from the page cache (truncate_inode_pages_range()), reclaim will block forever waiting for the lock since readahead cannot relinquish the lock because it is itself blocked in reclaim:
>>> stack_trace(1504735) folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate.c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache.c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c:221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195:3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/x86/mm/fault.c:1481:3) exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27
Fix this deadlock by allocating ff->release_args and grabbing the reference on the inode when preparing the file for release even if the server does not implement open. The inode reference will be dropped when the last reference on the fuse file is dropped (see fuse_file_put() -> fuse_release_end()).(CVE-2025-68821)
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix off-by-one issues in iavf_config_rss_reg()
There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX which is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4
where rss_{key,lut}_size / 4 is the number of dwords, so the last
valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <=
accesses one element past the end.
Fix the issues by using < instead of <=, ensuring we do not exceed
the bounds.
[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)
In the Linux kernel, the following vulnerability has been resolved:
e1000: fix OOB in e1000_tbi_should_accept()
In e1000_tbi_should_accept() we read the last byte of the frame via 'data[length - 1]' to evaluate the TBI workaround. If the descriptor- reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq):
================================================================== BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790 Read of size 1 at addr ffff888014114e54 by task sshd/363
CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 </IRQ> <TASK> __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f511b476b10 Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 </TASK> Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30 The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800] The buggy address belongs to the physical page: page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110 head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected ==================================================================
This happens because the TBI check unconditionally dereferences the last byte without validating the reported length first:
u8 last_byte = *(data + length - 1);
Fix by rejecting the frame early if the length is zero, or if it exceeds adapter->rx_buffer_len. This preserves the TBI workaround semantics for valid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Handle incorrect num_connectors capability
The UCSI spec states that the num_connectors field is 7 bits, and the 8th bit is reserved and should be set to zero. Some buggy FW has been known to set this bit, and it can lead to a system not booting. Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly.
Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported.(CVE-2025-71108)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - zero initialize memory allocated via sock_kmalloc
Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future.
The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures.
A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit:
67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")
Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:
https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209
The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.(CVE-2025-71113)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/kexec: Enable SMT before waking offline CPUs
If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed:
kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc [snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec
This occurs as add_cpu() fails due to cpu_bootable() returning false for CPUs that fail the cpu_smt_thread_allowed() check or non primary threads if SMT is disabled.
Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.(CVE-2025-71119)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Do not register unsupported perf events
Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:
------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:
# perf record -e synthetic:futex_wait Error: The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.
Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.(CVE-2025-71125)
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory and information leak in smb3_reconfigure()
In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak.
Fix this by calling kfree_sensitive() on both password buffers before returning in this error case.(CVE-2025-71151)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"perf-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-138.0.0.132.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-138.0.0.132.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"perf-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-138.0.0.132.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-138.0.0.132.oe2403sp2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()\n\nJakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()\nto increase test coverage.\n\nsyzbot found a splat caused by hard irq blocking in\nptr_ring_resize_multiple() [1]\n\nAs current users of ptr_ring_resize_multiple() do not require\nhard irqs being masked, replace it to only block BH.\n\nRename helpers to better reflect they are safe against BH only.\n\n- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()\n- skb_array_resize_multiple() to skb_array_resize_multiple_bh()\n\n[1]\n\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nModules linked in:\nCPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]\nRIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nCode: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 \u0026lt;0f\u0026gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85\nRSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083\nRAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000\nRDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843\nRBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d\nR10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040\nR13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff\nFS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tun_ptr_free drivers/net/tun.c:617 [inline]\n __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline]\n ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline]\n tun_queue_resize drivers/net/tun.c:3694 [inline]\n tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714\n notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93\n call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]\n call_netdevice_notifiers net/core/dev.c:2046 [inline]\n dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024\n do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923\n rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201\n rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550(CVE-2024-57994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params\n\nEach cpu DAI should associate with a widget. However, the topology might\nnot create the right number of DAI widgets for aggregated amps. And it\nwill cause NULL pointer deference.\nCheck that the DAI widget associated with the CPU DAI is valid to prevent\nNULL pointer deference due to missing DAI widgets in topologies with\naggregated amps.(CVE-2024-58012)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential NULL pointer dereference in dev_uevent()\n\nIf userspace reads \u0026quot;uevent\u0026quot; device attribute at the same time as another\nthreads unbinds the device from its driver, change to dev-\u0026gt;driver from a\nvalid pointer to NULL may result in crash. Fix this by using READ_ONCE()\nwhen fetching the pointer, and take bus\u0026apos; drivers klist lock to make sure\ndriver instance will not disappear while we access it.\n\nUse WRITE_ONCE() when setting the driver pointer to ensure there is no\ntearing.(CVE-2025-37800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds clause 45 read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via C45 (clause 45) mdiobus,\nthere is no verification of parameters passed to the ioctl and\nit accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before C45 read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via mdiobus, there is no verification of\nparameters passed to the ioctl and it accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: clear phydev-\u0026gt;devlink when the link is deleted\n\nThere is a potential crash issue when disabling and re-enabling the\nnetwork port. When disabling the network port, phy_detach() calls\ndevice_link_del() to remove the device link, but it does not clear\nphydev-\u0026gt;devlink, so phydev-\u0026gt;devlink is not a NULL pointer. Then the\nnetwork port is re-enabled, but if phy_attach_direct() fails before\ncalling device_link_add(), the code jumps to the \u0026quot;error\u0026quot; label and\ncalls phy_detach(). Since phydev-\u0026gt;devlink retains the old value from\nthe previous attach/detach cycle, device_link_del() uses the old value,\nwhich accesses a NULL pointer and causes a crash. The simplified crash\nlog is as follows.\n\n[ 24.702421] Call trace:\n[ 24.704856] device_link_put_kref+0x20/0x120\n[ 24.709124] device_link_del+0x30/0x48\n[ 24.712864] phy_detach+0x24/0x168\n[ 24.716261] phy_attach_direct+0x168/0x3a4\n[ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c\n[ 24.725140] phylink_of_phy_connect+0x1c/0x34\n\nTherefore, phydev-\u0026gt;devlink needs to be cleared when the device link is\ndeleted.(CVE-2025-38149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: prevent overflow in lookup table allocation\n\nWhen calculating the lookup table size, ensure the following\nmultiplication does not overflow:\n\n- desc-\u0026gt;field_len[] maximum value is U8_MAX multiplied by\n NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.\n- NFT_PIPAPO_BUCKETS(f-\u0026gt;bb) is 2^8, worst case.\n- sizeof(unsigned long), from sizeof(*f-\u0026gt;lt), lt in\n struct nft_pipapo_field.\n\nThen, use check_mul_overflow() to multiply by bucket size and then use\ncheck_add_overflow() to the alignment for avx2 (if needed). Finally, add\nlt_size_check_overflow() helper and use it to consolidate this.\n\nWhile at it, replace leftover allocation using the GFP_KERNEL to\nGFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().(CVE-2025-38162)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: add NULL check in automount_fullpath\n\npage is checked for null in __build_path_from_dentry_optional_prefix\nwhen tcon-\u0026gt;origin_fullpath is not set. However, the check is missing when\nit is set.\nAdd a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix race between nfsd registration and exports_proc\n\nAs of now nfsd calls create_proc_exports_entry() at start of init_nfsd\nand cleanup by remove_proc_entry() at last of exit_nfsd.\n\nWhich causes kernel OOPs if there is race between below 2 operations:\n(i) exportfs -r\n(ii) mount -t nfsd none /proc/fs/nfsd\n\nfor 5.4 kernel ARM64:\n\nCPU 1:\nel1_irq+0xbc/0x180\narch_counter_get_cntvct+0x14/0x18\nrunning_clock+0xc/0x18\npreempt_count_add+0x88/0x110\nprep_new_page+0xb0/0x220\nget_page_from_freelist+0x2d8/0x1778\n__alloc_pages_nodemask+0x15c/0xef0\n__vmalloc_node_range+0x28c/0x478\n__vmalloc_node_flags_caller+0x8c/0xb0\nkvmalloc_node+0x88/0xe0\nnfsd_init_net+0x6c/0x108 [nfsd]\nops_init+0x44/0x170\nregister_pernet_operations+0x114/0x270\nregister_pernet_subsys+0x34/0x50\ninit_nfsd+0xa8/0x718 [nfsd]\ndo_one_initcall+0x54/0x2e0\n\nCPU 2 :\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000010\n\nPC is at : exports_net_open+0x50/0x68 [nfsd]\n\nCall trace:\nexports_net_open+0x50/0x68 [nfsd]\nexports_proc_open+0x2c/0x38 [nfsd]\nproc_reg_open+0xb8/0x198\ndo_dentry_open+0x1c4/0x418\nvfs_open+0x38/0x48\npath_openat+0x28c/0xf18\ndo_filp_open+0x70/0xe8\ndo_sys_open+0x154/0x248\n\nSometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().\n\nand same is happening on latest 6.14 kernel as well:\n\n[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty\n...\n[ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48\n...\n[ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4\n...\n[ 285.469695] Call trace:\n[ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)\n[ 285.470488] seq_read+0xe0/0x11c\n[ 285.470675] proc_reg_read+0x9c/0xf0\n[ 285.470874] vfs_read+0xc4/0x2fc\n[ 285.471057] ksys_read+0x6c/0xf4\n[ 285.471231] __arm64_sys_read+0x1c/0x28\n[ 285.471428] invoke_syscall+0x44/0x100\n[ 285.471633] el0_svc_common.constprop.0+0x40/0xe0\n[ 285.471870] do_el0_svc_compat+0x1c/0x34\n[ 285.472073] el0_svc_compat+0x2c/0x80\n[ 285.472265] el0t_32_sync_handler+0x90/0x140\n[ 285.472473] el0t_32_sync+0x19c/0x1a0\n[ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)\n[ 285.473422] ---[ end trace 0000000000000000 ]---\n\nIt reproduced simply with below script:\nwhile [ 1 ]\ndo\n/exportfs -r\ndone \u0026amp;\n\nwhile [ 1 ]\ndo\ninsmod /nfsd.ko\nmount -t nfsd none /proc/fs/nfsd\numount /proc/fs/nfsd\nrmmod nfsd\ndone \u0026amp;\n\nSo exporting interfaces to user space shall be done at last and\ncleanup at first place.\n\nWith change there is no Kernel OOPs.(CVE-2025-38232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential deadlock when reconnecting channels\n\nFix cifs_signal_cifsd_for_reconnect() to take the correct lock order\nand prevent the following deadlock from happening\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.16.0-rc3-build2+ #1301 Tainted: G S W\n------------------------------------------------------\ncifsd/6055 is trying to acquire lock:\nffff88810ad56038 (\u0026amp;tcp_ses-\u0026gt;srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200\n\nbut task is already holding lock:\nffff888119c64330 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}:\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_setup_session+0x81/0x4b0\n cifs_get_smb_ses+0x771/0x900\n cifs_mount_get_session+0x7e/0x170\n cifs_mount+0x92/0x2d0\n cifs_smb3_do_mount+0x161/0x460\n smb3_get_tree+0x55/0x90\n vfs_get_tree+0x46/0x180\n do_new_mount+0x1b0/0x2e0\n path_mount+0x6ee/0x740\n do_mount+0x98/0xe0\n __do_sys_mount+0x148/0x180\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #1 (\u0026amp;ret_buf-\u0026gt;ses_lock){+.+.}-{3:3}:\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_match_super+0x101/0x320\n sget+0xab/0x270\n cifs_smb3_do_mount+0x1e0/0x460\n smb3_get_tree+0x55/0x90\n vfs_get_tree+0x46/0x180\n do_new_mount+0x1b0/0x2e0\n path_mount+0x6ee/0x740\n do_mount+0x98/0xe0\n __do_sys_mount+0x148/0x180\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #0 (\u0026amp;tcp_ses-\u0026gt;srv_lock){+.+.}-{3:3}:\n check_noncircular+0x95/0xc0\n check_prev_add+0x115/0x2f0\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_signal_cifsd_for_reconnect+0x134/0x200\n __cifs_reconnect+0x8f/0x500\n cifs_handle_standard+0x112/0x280\n cifs_demultiplex_thread+0x64d/0xbc0\n kthread+0x2f7/0x310\n ret_from_fork+0x2a/0x230\n ret_from_fork_asm+0x1a/0x30\n\nother info that might help us debug this:\n\nChain exists of:\n \u0026amp;tcp_ses-\u0026gt;srv_lock --\u0026gt; \u0026amp;ret_buf-\u0026gt;ses_lock --\u0026gt; \u0026amp;ret_buf-\u0026gt;chan_lock\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;ret_buf-\u0026gt;chan_lock);\n lock(\u0026amp;ret_buf-\u0026gt;ses_lock);\n lock(\u0026amp;ret_buf-\u0026gt;chan_lock);\n lock(\u0026amp;tcp_ses-\u0026gt;srv_lock);\n\n *** DEADLOCK ***\n\n3 locks held by cifsd/6055:\n #0: ffffffff857de398 (\u0026amp;cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200\n #1: ffff888119c64060 (\u0026amp;ret_buf-\u0026gt;ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200\n #2: ffff888119c64330 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200(CVE-2025-38244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoftware node: Correct a OOB check in software_node_get_reference_args()\n\nsoftware_node_get_reference_args() wants to get @index-th element, so\nthe property value requires at least \u0026apos;(index + 1) * sizeof(*ref)\u0026apos; bytes\nbut that can not be guaranteed by current OOB check, and may cause OOB\nfor malformed property.\n\nFix by using as OOB check \u0026apos;((index + 1) * sizeof(*ref) \u0026gt; prop-\u0026gt;length)\u0026apos;.(CVE-2025-38342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN\n\nWe found a few different systems hung up in writeback waiting on the same\npage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in\npnfs_update_layout(), however the pnfs_layout_hdr\u0026apos;s plh_outstanding count\nwas zero.\n\nIt seems most likely that this is another race between the waiter and waker\nsimilar to commit ed0172af5d6f (\u0026quot;SUNRPC: Fix a race to wake a sync task\u0026quot;).\nFix it up by applying the advised barrier.(CVE-2025-38393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight\n\nReject migration of SEV{-ES} state if either the source or destination VM\nis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the\nsection between incrementing created_vcpus and online_vcpus. The bulk of\nvCPU creation runs _outside_ of kvm-\u0026gt;lock to allow creating multiple vCPUs\nin parallel, and so sev_info.es_active can get toggled from false=\u0026gt;true in\nthe destination VM after (or during) svm_vcpu_create(), resulting in an\nSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.\n\nThe issue manifests most visibly as a crash when trying to free a vCPU\u0026apos;s\nNULL VMSA page in an SEV-ES VM, but any number of things can go wrong.\n\n BUG: unable to handle page fault for address: ffffebde00000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP KASAN NOPTI\n CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024\n RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]\n RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]\n RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]\n RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]\n RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067\n Code: \u0026lt;49\u0026gt; f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0\n RSP: 0018:ffff8984551978d0 EFLAGS: 00010246\n RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98\n RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000\n RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000\n R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000\n R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000\n FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0\n DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169\n svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515\n kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396\n kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]\n kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490\n kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895\n kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310\n kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369\n __fput+0x3e4/0x9e0 fs/file_table.c:465\n task_work_run+0x1a9/0x220 kernel/task_work.c:227\n exit_task_work include/linux/task_work.h:40 [inline]\n do_exit+0x7f0/0x25b0 kernel/exit.c:953\n do_group_exit+0x203/0x2d0 kernel/exit.c:1102\n get_signal+0x1357/0x1480 kernel/signal.c:3034\n arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218\n do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f87a898e969\n \u0026lt;/TASK\u0026gt;\n Modules linked in: gq(O)\n gsmi: Log Shutdown Reason 0x03\n CR2: ffffebde00000000\n ---[ end trace 0000000000000000 ]---\n\nDeliberately don\u0026apos;t check for a NULL VMSA when freeing the vCPU, as crashing\nthe host is likely desirable due to the VMSA being consumed by hardware.\nE.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a\nbogus VMSA page. Accessing P\n---truncated---(CVE-2025-38455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Abort __tc_modify_qdisc if parent class does not exist\n\nLion\u0026apos;s patch [1] revealed an ancient bug in the qdisc API.\nWhenever a user creates/modifies a qdisc specifying as a parent another\nqdisc, the qdisc API will, during grafting, detect that the user is\nnot trying to attach to a class and reject. However grafting is\nperformed after qdisc_create (and thus the qdiscs\u0026apos; init callback) is\nexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlog\nduring init or change (such as fq, hhf, choke, etc), an issue\narises. For example, executing the following commands:\n\nsudo tc qdisc add dev lo root handle a: htb default 2\nsudo tc qdisc add dev lo parent a: handle beef fq\n\nQdiscs such as fq, hhf, choke, etc unconditionally invoke\nqdisc_tree_reduce_backlog() in their control path init() or change() which\nthen causes a failure to find the child class; however, that does not stop\nthe unconditional invocation of the assumed child qdisc\u0026apos;s qlen_notify with\na null class. All these qdiscs make the assumption that class is non-null.\n\nThe solution is ensure that qdisc_leaf() which looks up the parent\nclass, and is invoked prior to qdisc_create(), should return failure on\nnot finding the class.\nIn this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the\nparentid doesn\u0026apos;t correspond to a class, so that we can detect it\nearlier on and abort before qdisc_create is called.\n\n[1] https://lore.kernel.org/netdev/(CVE-2025-38457)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Prevent ALIGN() overflow\n\nWhen allocating IOVA the candidate range gets aligned to the target\nalignment. If the range is close to ULONG_MAX then the ALIGN() can\nwrap resulting in a corrupted iova.\n\nOpen code the ALIGN() using get_add_overflow() to prevent this.\nThis simplifies the checks as we don\u0026apos;t need to check for length earlier\neither.\n\nConsolidate the two copies of this code under a single helper.\n\nThis bug would allow userspace to create a mapping that overlaps with some\nother mapping or a reserved range.(CVE-2025-38688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: upper bound check of tree index in dbAllocAG\n\nWhen computing the tree index in dbAllocAG, we never check if we are\nout of bounds realative to the size of the stree.\nThis could happen in a scenario where the filesystem metadata are\ncorrupted.(CVE-2025-38697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: don\u0026apos;t use BUG_ON() in hfsplus_create_attributes_file()\n\nWhen the volume header contains erroneous values that do not reflect\nthe actual state of the filesystem, hfsplus_fill_super() assumes that\nthe attributes file is not yet created, which later results in hitting\nBUG_ON() when hfsplus_create_attributes_file() is called. Replace this\nBUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nThe hfsplus_readdir() method is capable to crash by calling\nhfsplus_uni2asc():\n\n[ 667.121659][ T9805] ==================================================================\n[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10\n[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805\n[ 667.124578][ T9805]\n[ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)\n[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 667.124890][ T9805] Call Trace:\n[ 667.124893][ T9805] \u0026lt;TASK\u0026gt;\n[ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0\n[ 667.124911][ T9805] print_report+0xd0/0x660\n[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610\n[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180\n[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124942][ T9805] kasan_report+0xc6/0x100\n[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10\n[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360\n[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0\n[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10\n[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0\n[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0\n[ 667.125022][ T9805] ? lock_acquire+0x30/0x80\n[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0\n[ 667.125044][ T9805] ? putname+0x154/0x1a0\n[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10\n[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0\n[ 667.125069][ T9805] iterate_dir+0x296/0xb20\n[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10\n[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200\n[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10\n[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0\n[ 667.125143][ T9805] do_syscall_64+0xc9/0x480\n[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9\n[ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48\n[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9\n[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9\n[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004\n[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110\n[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260\n[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 667.125207][ T9805] \u0026lt;/TASK\u0026gt;\n[ 667.125210][ T9805]\n[ 667.145632][ T9805] Allocated by task 9805:\n[ 667.145991][ T9805] kasan_save_stack+0x20/0x40\n[ 667.146352][ T9805] kasan_save_track+0x14/0x30\n[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0\n[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550\n[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0\n[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0\n[ 667.148174][ T9805] iterate_dir+0x296/0xb20\n[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.148937][ T9805] do_syscall_64+0xc9/0x480\n[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.149809][ T9805]\n[ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000\n[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048\n[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of\n[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)\n[ 667.1\n---truncated---(CVE-2025-38713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()\n\nThe hfsplus_bnode_read() method can trigger the issue:\n\n[ 174.852007][ T9784] ==================================================================\n[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360\n[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784\n[ 174.854059][ T9784]\n[ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)\n[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 174.854286][ T9784] Call Trace:\n[ 174.854289][ T9784] \u0026lt;TASK\u0026gt;\n[ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0\n[ 174.854305][ T9784] print_report+0xd0/0x660\n[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610\n[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180\n[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854337][ T9784] kasan_report+0xc6/0x100\n[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360\n[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380\n[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10\n[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0\n[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310\n[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0\n[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0\n[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10\n[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10\n[ 174.854436][ T9784] ? __asan_memset+0x23/0x50\n[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320\n[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10\n[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0\n[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0\n[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10\n[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0\n[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10\n[ 174.854525][ T9784] ? down_write+0x148/0x200\n[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10\n[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0\n[ 174.854549][ T9784] do_unlinkat+0x490/0x670\n[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10\n[ 174.854565][ T9784] ? __might_fault+0xbc/0x130\n[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550\n[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110\n[ 174.854592][ T9784] do_syscall_64+0xc9/0x480\n[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167\n[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08\n[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057\n[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167\n[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50\n[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40\n[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0\n[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 174.854658][ T9784] \u0026lt;/TASK\u0026gt;\n[ 174.854661][ T9784]\n[ 174.879281][ T9784] Allocated by task 9784:\n[ 174.879664][ T9784] kasan_save_stack+0x20/0x40\n[ 174.880082][ T9784] kasan_save_track+0x14/0x30\n[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0\n[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550\n[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890\n[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10\n[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520\n[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3\n---truncated---(CVE-2025-38714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix for slab out of bounds on mount to ksmbd\n\nWith KASAN enabled, it is possible to get a slab out of bounds\nduring mount to ksmbd due to missing check in parse_server_interfaces()\n(see below):\n\n BUG: KASAN: slab-out-of-bounds in\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n Read of size 4 at addr ffff8881433dba98 by task mount/9827\n\n CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G\n OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary)\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,\n BIOS 2.13.1 06/14/2019\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x9f/0xf0\n print_report+0xd1/0x670\n __virt_addr_valid+0x22c/0x430\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? kasan_complete_mode_report_info+0x2a/0x1f0\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n kasan_report+0xd6/0x110\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n __asan_report_load_n_noabort+0x13/0x20\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]\n ? trace_hardirqs_on+0x51/0x60\n SMB3_request_interfaces+0x1ad/0x3f0 [cifs]\n ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]\n ? SMB2_tcon+0x23c/0x15d0 [cifs]\n smb3_qfs_tcon+0x173/0x2b0 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n cifs_mount_get_tcon+0x369/0xb90 [cifs]\n ? dfs_cache_find+0xe7/0x150 [cifs]\n dfs_mount_share+0x985/0x2970 [cifs]\n ? check_path.constprop.0+0x28/0x50\n ? save_trace+0x54/0x370\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? __lock_acquire+0xb82/0x2ba0\n ? __kasan_check_write+0x18/0x20\n cifs_mount+0xbc/0x9e0 [cifs]\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]\n cifs_smb3_do_mount+0x263/0x1990 [cifs](CVE-2025-38728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix refcount leak causing resource not released\n\nWhen ksmbd_conn_releasing(opinfo-\u0026gt;conn) returns true,the refcount was not\ndecremented properly, causing a refcount leak that prevents the count from\nreaching zero and the memory from being released.(CVE-2025-39720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix filehandle bounds checking in nfs_fh_to_dentry()\n\nThe function needs to check the minimal filehandle length before it can\naccess the embedded filehandle.(CVE-2025-39730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel. Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects. The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue. In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn\u0026apos;t really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen. So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.(CVE-2025-39737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix the setting of capabilities when automounting a new filesystem\n\nCapabilities cannot be inherited when we cross into a new filesystem.\nThey need to be reset to the minimal defaults, and then probed for\nagain.(CVE-2025-39798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: use array_index_nospec with indices that come from guest\n\nmin and dest_id are guest-controlled indices. Using array_index_nospec()\nafter the bounds checks clamps these values to mitigate speculative execution\nside-channels.(CVE-2025-39823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().\n\nsyzbot reported the splat below. [0]\n\nWhen atmtcp_v_open() or atmtcp_v_close() is called via connect()\nor close(), atmtcp_send_control() is called to send an in-kernel\nspecial message.\n\nThe message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.\nAlso, a pointer of struct atm_vcc is set to atmtcp_control.vcc.\n\nThe notable thing is struct atmtcp_control is uAPI but has a\nspace for an in-kernel pointer.\n\n struct atmtcp_control {\n \tstruct atmtcp_hdr hdr;\t/* must be first */\n ...\n \tatm_kptr_t vcc;\t\t/* both directions */\n ...\n } __ATM_API_ALIGN;\n\n typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;\n\nThe special message is processed in atmtcp_recv_control() called\nfrom atmtcp_c_send().\n\natmtcp_c_send() is vcc-\u0026gt;dev-\u0026gt;ops-\u0026gt;send() and called from 2 paths:\n\n 1. .ndo_start_xmit() (vcc-\u0026gt;send() == atm_send_aal0())\n 2. vcc_sendmsg()\n\nThe problem is sendmsg() does not validate the message length and\nuserspace can abuse atmtcp_recv_control() to overwrite any kptr\nby atmtcp_control.\n\nLet\u0026apos;s add a new -\u0026gt;pre_send() hook to validate messages from sendmsg().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI\nKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]\nCPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]\nRIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297\nCode: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c\nRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203\nRAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c\nRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd\nR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000\nR13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff\nFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n ____sys_sendmsg+0x505/0x830 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f8d7e96a4a9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9\nRDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005\nRBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f\nR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac\nR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250\n \u0026lt;/TASK\u0026gt;\nModules linked in:(CVE-2025-39828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix OOB read/write in network-coding decode\n\nbatadv_nc_skb_decode_packet() trusts coded_len and checks only against\nskb-\u0026gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing\npayload headroom, and the source skb length is not verified, allowing an\nout-of-bounds read and a small out-of-bounds write.\n\nValidate that coded_len fits within the payload area of both destination\nand source sk_buffs before XORing.(CVE-2025-39839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix race condition validating r_parent before applying state\n\nAdd validation to ensure the cached parent directory inode matches the\ndirectory info in MDS replies. This prevents client-side race conditions\nwhere concurrent operations (e.g. rename) cause r_parent to become stale\nbetween request initiation and reply processing, which could lead to\napplying state changes to incorrect directory inodes.\n\n[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to\n move CEPH_CAP_PIN reference when r_parent is updated:\n\n When the parent directory lock is not held, req-\u0026gt;r_parent can become\n stale and is updated to point to the correct inode. However, the\n associated CEPH_CAP_PIN reference was not being adjusted. The\n CEPH_CAP_PIN is a reference on an inode that is tracked for\n accounting purposes. Moving this pin is important to keep the\n accounting balanced. When the pin was not moved from the old parent\n to the new one, it created two problems: The reference on the old,\n stale parent was never released, causing a reference leak.\n A reference for the new parent was never acquired, creating the risk\n of a reference underflow later in ceph_mdsc_release_request(). This\n patch corrects the logic by releasing the pin from the old parent and\n acquiring it for the new parent when r_parent is switched. This\n ensures reference accounting stays balanced. ](CVE-2025-39927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path\n\nDuring tests of another unrelated patch I was able to trigger this\nerror: Objects remaining on __kmem_cache_shutdown()(CVE-2025-39929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: virtio_uml: Fix use-after-free after put_device in probe\n\nWhen register_virtio_device() fails in virtio_uml_probe(),\nthe code sets vu_dev-\u0026gt;registered = 1 even though\nthe device was not successfully registered.\nThis can lead to use-after-free or other issues.(CVE-2025-39951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: tuner: xc5000: Fix use-after-free in xc5000_release\n\nThe original code uses cancel_delayed_work() in xc5000_release(), which\ndoes not guarantee that the delayed work item timer_sleep has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere xc5000_release() may free the xc5000_priv while timer_sleep is still\nactive and attempts to dereference the xc5000_priv.\n\nA typical race condition is illustrated below:\n\nCPU 0 (release thread) | CPU 1 (delayed work callback)\nxc5000_release() | xc5000_do_timer_sleep()\n cancel_delayed_work() |\n hybrid_tuner_release_state(priv) |\n kfree(priv) |\n | priv = container_of() // UAF\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the timer_sleep is properly canceled before the xc5000_priv memory\nis deallocated.\n\nA deadlock concern was considered: xc5000_release() is called in a process\ncontext and is not holding any locks that the timer_sleep work item might\nalso need. Therefore, the use of the _sync() variant is safe here.\n\nThis bug was initially identified through static analysis.\n\n[hverkuil: fix typo in Subject: tunner -\u0026gt; tuner](CVE-2025-39994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Disallow dirty tracking if incoherent page walk\n\nDirty page tracking relies on the IOMMU atomically updating the dirty bit\nin the paging-structure entry. For this operation to succeed, the paging-\nstructure memory must be coherent between the IOMMU and the CPU. In\nanother word, if the iommu page walk is incoherent, dirty page tracking\ndoesn\u0026apos;t work.\n\nThe Intel VT-d specification, Section 3.10 \u0026quot;Snoop Behavior\u0026quot; states:\n\n\u0026quot;Remapping hardware encountering the need to atomically update A/EA/D bits\n in a paging-structure entry that is not snooped will result in a non-\n recoverable fault.\u0026quot;\n\nTo prevent an IOMMU from being incorrectly configured for dirty page\ntracking when it is operating in an incoherent mode, mark SSADS as\nsupported only when both ecap_slads and ecap_smpwc are supported.(CVE-2025-40058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Define a proc_layoutcommit for the FlexFiles layout type\n\nAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT\noperation on a FlexFiles layout.(CVE-2025-40087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: parse_dfs_referrals: prevent oob on malformed input\n\nMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS\n\n- reply smaller than sizeof(struct get_dfs_referral_rsp)\n- reply with number of referrals smaller than NumberOfReferrals in the\nheader\n\nProcessing of such replies will cause oob.\n\nReturn -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix refcount leak for cifs_sb_tlink\n\nFix three refcount inconsistency issues related to `cifs_sb_tlink`.\n\nComments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be\ncalled after successful calls to `cifs_sb_tlink()`. Three calls fail to\nupdate refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix Use-after-free in validation\n\nNodes stored in the validation duplicates hashtable come from an arena\nallocator that is cleared at the end of vmw_execbuf_process. All nodes\nare expected to be cleared in vmw_validation_drop_ht but this node escaped\nbecause its resource was destroyed prematurely.(CVE-2025-40111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Clean up only new IRQ glue on request_irq() failure\n\nThe mlx5_irq_alloc() function can inadvertently free the entire rmap\nand end up in a crash[1] when the other threads tries to access this,\nwhen request_irq() fails due to exhausted IRQ vectors. This commit\nmodifies the cleanup to remove only the specific IRQ mapping that was\njust added.\n\nThis prevents removal of other valid mappings and ensures precise\ncleanup of the failed IRQ allocation\u0026apos;s associated glue object.\n\nNote: This error is observed when both fwctl and rds configs are enabled.\n\n[1]\nmlx5_core 0000:05:00.0: Successfully registered panic handler for port 1\nmlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to\nrequest irq. err = -28\ninfiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while\ntrying to test write-combining support\nmlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1\nmlx5_core 0000:06:00.0: Successfully registered panic handler for port 1\nmlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to\nrequest irq. err = -28\ninfiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while\ntrying to test write-combining support\nmlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1\nmlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to\nrequest irq. err = -28\nmlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to\nrequest irq. err = -28\ngeneral protection fault, probably for non-canonical address\n0xe277a58fde16f291: 0000 [#1] SMP NOPTI\n\nRIP: 0010:free_irq_cpu_rmap+0x23/0x7d\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_trace_log_lvl+0x1d6/0x2f9\n ? show_trace_log_lvl+0x1d6/0x2f9\n ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]\n ? __die_body.cold+0x8/0xa\n ? die_addr+0x39/0x53\n ? exc_general_protection+0x1c4/0x3e9\n ? dev_vprintk_emit+0x5f/0x90\n ? asm_exc_general_protection+0x22/0x27\n ? free_irq_cpu_rmap+0x23/0x7d\n mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]\n irq_pool_request_vector+0x7d/0x90 [mlx5_core]\n mlx5_irq_request+0x2e/0xe0 [mlx5_core]\n mlx5_irq_request_vector+0xad/0xf7 [mlx5_core]\n comp_irq_request_pci+0x64/0xf0 [mlx5_core]\n create_comp_eq+0x71/0x385 [mlx5_core]\n ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core]\n mlx5_comp_eqn_get+0x72/0x90 [mlx5_core]\n ? xas_load+0x8/0x91\n mlx5_comp_irqn_get+0x40/0x90 [mlx5_core]\n mlx5e_open_channel+0x7d/0x3c7 [mlx5_core]\n mlx5e_open_channels+0xad/0x250 [mlx5_core]\n mlx5e_open_locked+0x3e/0x110 [mlx5_core]\n mlx5e_open+0x23/0x70 [mlx5_core]\n __dev_open+0xf1/0x1a5\n __dev_change_flags+0x1e1/0x249\n dev_change_flags+0x21/0x5c\n do_setlink+0x28b/0xcc4\n ? __nla_parse+0x22/0x3d\n ? inet6_validate_link_af+0x6b/0x108\n ? cpumask_next+0x1f/0x35\n ? __snmp6_fill_stats64.constprop.0+0x66/0x107\n ? __nla_validate_parse+0x48/0x1e6\n __rtnl_newlink+0x5ff/0xa57\n ? kmem_cache_alloc_trace+0x164/0x2ce\n rtnl_newlink+0x44/0x6e\n rtnetlink_rcv_msg+0x2bb/0x362\n ? __netlink_sendskb+0x4c/0x6c\n ? netlink_unicast+0x28f/0x2ce\n ? rtnl_calcit.isra.0+0x150/0x146\n netlink_rcv_skb+0x5f/0x112\n netlink_unicast+0x213/0x2ce\n netlink_sendmsg+0x24f/0x4d9\n __sock_sendmsg+0x65/0x6a\n ____sys_sendmsg+0x28f/0x2c9\n ? import_iovec+0x17/0x2b\n ___sys_sendmsg+0x97/0xe0\n __sys_sendmsg+0x81/0xd8\n do_syscall_64+0x35/0x87\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\nRIP: 0033:0x7fc328603727\nCode: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed\nff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00\nf0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48\nRSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727\nRDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d\nRBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\nR13: 00000000000\n---truncated---(CVE-2025-40250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()\n\nThe loops in \u0026apos;qede_tpa_cont()\u0026apos; and \u0026apos;qede_tpa_end()\u0026apos;, iterate\nover \u0026apos;cqe-\u0026gt;len_list[]\u0026apos; using only a zero-length terminator as\nthe stopping condition. If the terminator was missing or\nmalformed, the loop could run past the end of the fixed-size array.\n\nAdd an explicit bound check using ARRAY_SIZE() in both loops to prevent\na potential out-of-bounds access.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Do not sleep in atomic context\n\nsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may\nsleep. Hence, call sg_finish_rem_req() with interrupts enabled instead\nof disabled.(CVE-2025-40259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: nvme-fc: Ensure -\u0026gt;ioerr_work is cancelled in nvme_fc_delete_ctrl()\n\nnvme_fc_delete_assocation() waits for pending I/O to complete before\nreturning, and an error can cause -\u0026gt;ioerr_work to be queued after\ncancel_work_sync() had been called. Move the call to cancel_work_sync() to\nbe after nvme_fc_delete_association() to ensure -\u0026gt;ioerr_work is not running\nwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:\n\n[ 1135.911754] list_del corruption, ff2d24c8093f31f8-\u0026gt;next is NULL\n[ 1135.917705] ------------[ cut here ]------------\n[ 1135.922336] kernel BUG at lib/list_debug.c:52!\n[ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)\n[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025\n[ 1135.950969] Workqueue: 0x0 (nvme-wq)\n[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b\n[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046\n[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000\n[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0\n[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08\n[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100\n[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0\n[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000\n[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0\n[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[ 1136.055910] PKRU: 55555554\n[ 1136.058623] Call Trace:\n[ 1136.061074] \u0026lt;TASK\u0026gt;\n[ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.071898] ? move_linked_works+0x4a/0xa0\n[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.081744] ? __die_body.cold+0x8/0x12\n[ 1136.085584] ? die+0x2e/0x50\n[ 1136.088469] ? do_trap+0xca/0x110\n[ 1136.091789] ? do_error_trap+0x65/0x80\n[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.101289] ? exc_invalid_op+0x50/0x70\n[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20\n[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.120806] move_linked_works+0x4a/0xa0\n[ 1136.124733] worker_thread+0x216/0x3a0\n[ 1136.128485] ? __pfx_worker_thread+0x10/0x10\n[ 1136.132758] kthread+0xfa/0x240\n[ 1136.135904] ? __pfx_kthread+0x10/0x10\n[ 1136.139657] ret_from_fork+0x31/0x50\n[ 1136.143236] ? __pfx_kthread+0x10/0x10\n[ 1136.146988] ret_from_fork_asm+0x1a/0x30\n[ 1136.150915] \u0026lt;/TASK\u0026gt;(CVE-2025-40261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: pass wrb_params in case of OS2BMC\n\nbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULL\nat be_send_pkt_to_bmc() call site.\u00a0 This may lead to dereferencing a NULL\npointer when processing a workaround for specific packet, as commit\nbc0c3405abbb (\u0026quot;be2net: fix a Tx stall bug caused by a specific ipv6\npacket\u0026quot;) states.\n\nThe correct way would be to pass the wrb_params from be_xmit().(CVE-2025-40264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: client: fix memory leak in smb3_fs_context_parse_param\n\nThe user calls fsconfig twice, but when the program exits, free() only\nfrees ctx-\u0026gt;source for the second fsconfig, not the first.\nRegarding fc-\u0026gt;source, there is no code in the fs context related to its\nmemory reclamation.\n\nTo fix this memory leak, release the source memory corresponding to ctx\nor fc before each parsing.\n\nsyzbot reported:\nBUG: memory leak\nunreferenced object 0xffff888128afa360 (size 96):\n backtrace (crc 79c9c7ba):\n kstrdup+0x3c/0x80 mm/util.c:84\n smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444\n\nBUG: memory leak\nunreferenced object 0xffff888112c7d900 (size 96):\n backtrace (crc 79c9c7ba):\n smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629\n smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: free copynotify stateid in nfs4_free_ol_stateid()\n\nTypically copynotify stateid is freed either when parent\u0026apos;s stateid\nis being close/freed or in nfsd4_laundromat if the stateid hasn\u0026apos;t\nbeen used in a lease period.\n\nHowever, in case when the server got an OPEN (which created\na parent stateid), followed by a COPY_NOTIFY using that stateid,\nfollowed by a client reboot. New client instance while doing\nCREATE_SESSION would force expire previous state of this client.\nIt leads to the open state being freed thru release_openowner-\u0026gt;\nnfs4_free_ol_stateid() and it finds that it still has copynotify\nstateid associated with it. We currently print a warning and is\ntriggerred\n\nWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]\n\nThis patch, instead, frees the associated copynotify stateid here.\n\nIf the parent stateid is freed (without freeing the copynotify\nstateids associated with it), it leads to the list corruption\nwhen laundromat ends up freeing the copynotify state later.\n\n[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink\n[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)\n[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN\n[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024\n[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd]\n[ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.861182] sp : ffff8000881d7a40\n[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200\n[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20\n[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8\n[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000\n[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065\n[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3\n[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000\n[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001\n[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000\n[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d\n[ 1626.868167] Call trace:\n[ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)\n[ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd]\n[ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd]\n[ 1626.869813] laundromat_main+0x24/0x60 [nfsd]\n[ 1626.870231] process_one_work+0x584/0x1050\n[ 1626.870595] worker_thread+0x4c4/0xc60\n[ 1626.870893] kthread+0x2f8/0x398\n[ 1626.871146] ret_from_fork+0x10/0x20\n[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)\n[ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: cancel mesh send timer when hdev removed\n\nmesh_send_done timer is not canceled when hdev is removed, which causes\ncrash if the timer triggers after hdev is gone.\n\nCancel the timer when MGMT removes the hdev, like other MGMT timers.\n\nShould fix the BUG: sporadically seen by BlueZ test bot\n(in \u0026quot;Mesh - Send cancel - 1\u0026quot; test).\n\nLog:\n------\nBUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0\n...\nFreed by task 36:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3a/0x60\n __kasan_slab_free+0x43/0x70\n kfree+0x103/0x500\n device_release+0x9a/0x210\n kobject_put+0x100/0x1e0\n vhci_release+0x18b/0x240\n------(CVE-2025-40284)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds\n\nAdd bounds checking to prevent writes past framebuffer boundaries when\nrendering text near screen edges. Return early if the Y position is off-screen\nand clip image height to screen boundary. Break from the rendering loop if the\nX position is off-screen. When clipping image width to fit the screen, update\nthe character count to match the clipped width to prevent buffer size\nmismatches.\n\nWithout the character count update, bit_putcs_aligned and bit_putcs_unaligned\nreceive mismatched parameters where the buffer is allocated for the clipped\nwidth but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naccel/habanalabs: support mapping cb with vmalloc-backed coherent memory\n\nWhen IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return\naddresses from the vmalloc range. If such an address is mapped without\nVM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the\nVM_PFNMAP restriction.\n\nFix this by checking for vmalloc addresses and setting VM_MIXEDMAP\nin the VMA before mapping. This ensures safe mapping and avoids kernel\ncrashes. The memory is still driver-allocated and cannot be accessed\ndirectly by userspace.(CVE-2025-40311)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget\n\nIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget\nstructure (pdev-\u0026gt;gadget) was freed before its endpoints.\nThe endpoints are linked via the ep_list in the gadget structure.\nFreeing the gadget first leaves dangling pointers in the endpoint list.\nWhen the endpoints are subsequently freed, this results in a use-after-free.\n\nFix:\nBy separating the usb_del_gadget_udc() operation into distinct \u0026quot;del\u0026quot; and\n\u0026quot;put\u0026quot; steps, cdnsp_gadget_free_endpoints() can be executed prior to the\nfinal release of the gadget structure with usb_put_gadget().\n\nA patch similar to bb9c74a5bd14(\u0026quot;usb: dwc3: gadget: Free gadget structure\n only after freeing endpoints\u0026quot;).(CVE-2025-40314)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Sync pending IRQ work before freeing ring buffer\n\nFix a race where irq_work can be queued in bpf_ringbuf_commit()\nbut the ring buffer is freed before the work executes.\nIn the syzbot reproducer, a BPF program attached to sched_switch\ntriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer\nis freed before this work executes, the irq_work thread may accesses\nfreed memory.\nCalling `irq_work_sync(\u0026amp;rb-\u0026gt;work)` ensures that all pending irq_work\ncomplete before freeing the buffer.(CVE-2025-40319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential cfid UAF in smb2_query_info_compound\n\nWhen smb2_query_info_compound() retries, a previously allocated cfid may\nhave been freed in the first attempt.\nBecause cfid wasn\u0026apos;t reset on replay, later cleanup could act on a stale\npointer, leading to a potential use-after-free.\n\nReinitialize cfid to NULL under the replay label.\n\nExample trace (trimmed):\n\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110\n[...]\nRIP: 0010:refcount_warn_saturate+0x9c/0x110\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n ? step_into+0x10d/0x690\n ? __legitimize_path+0x28/0x60\n smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n ? kmem_cache_alloc+0x18a/0x340\n ? getname_flags+0x46/0x1e0\n cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n statfs_by_dentry+0x67/0x90\n vfs_statfs+0x16/0xd0\n user_statfs+0x54/0xa0\n __do_sys_statfs+0x20/0x50\n do_syscall_64+0x58/0x80(CVE-2025-40320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: bitblit: bound-check glyph index in bit_putcs*\n\nbit_putcs_aligned()/unaligned() derived the glyph pointer from the\ncharacter value masked by 0xff/0x1ff, which may exceed the actual font\u0026apos;s\nglyph count and read past the end of the built-in font array.\nClamp the index to the actual glyph count before computing the address.\n\nThis fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Fix crash in nfsd4_read_release()\n\nWhen tracing is enabled, the trace_nfsd_read_done trace point\ncrashes during the pynfs read.testNoFh test.(CVE-2025-40324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in smb2_close_cached_fid()\n\nfind_or_create_cached_dir() could grab a new reference after kref_put()\nhad seen the refcount drop to zero but before cfid_list_lock is acquired\nin smb2_close_cached_fid(), leading to use-after-free.\n\nSwitch to kref_put_lock() so cfid_release() is called with\ncfid_list_lock held, closing that gap.(CVE-2025-40328)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: sddr55: Reject out-of-bound new_pba\n\nDiscovered by Atuin - Automated Vulnerability Discovery Engine.\n\nnew_pba comes from the status packet returned after each write.\nA bogus device could report values beyond the block count derived\nfrom info-\u0026gt;capacity, letting the driver walk off the end of\npba_to_lba[] and corrupt heap memory.\n\nReject PBAs that exceed the computed block count and fail the\ntransfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ\n\nXDP programs can change the layout of an xdp_buff through\nbpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver\ncannot assume the size of the linear data area nor fragments. Fix the\nbug in mlx5 by generating skb according to xdp_buff after XDP programs\nrun.\n\nCurrently, when handling multi-buf XDP, the mlx5 driver assumes the\nlayout of an xdp_buff to be unchanged. That is, the linear data area\ncontinues to be empty and fragments remain the same. This may cause\nthe driver to generate erroneous skb or triggering a kernel\nwarning. When an XDP program added linear data through\nbpf_xdp_adjust_head(), the linear data will be ignored as\nmlx5e_build_linear_skb() builds an skb without linear data and then\npull data from fragments to fill the linear data area. When an XDP\nprogram has shrunk the non-linear data through bpf_xdp_adjust_tail(),\nthe delta passed to __pskb_pull_tail() may exceed the actual nonlinear\ndata size and trigger the BUG_ON in it.\n\nTo fix the issue, first record the original number of fragments. If the\nnumber of fragments changes after the XDP program runs, rewind the end\nfragment pointer by the difference and recalculate the truesize. Then,\nbuild the skb with the linear data area matching the xdp_buff. Finally,\nonly pull data in if there is non-linear data and fill the linear part\nup to 256 bytes.(CVE-2025-40350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sysfb: Do not dereference NULL pointer in plane reset\n\nThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not\nderef that pointer, but forward NULL to the other plane-reset helpers.\nClears plane-\u0026gt;state to NULL.\n\nv2:\n- fix typo in commit description (Javier)(CVE-2025-40360)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: fix field-spanning memcpy warning in AH output\n\nFix field-spanning memcpy warnings in ah6_output() and\nah6_output_done() where extension headers are copied to/from IPv6\naddress fields, triggering fortify-string warnings about writes beyond\nthe 16-byte address fields.\n\n memcpy: detected field-spanning write (size 40) of single field \u0026quot;\u0026amp;top_iph-\u0026gt;saddr\u0026quot; at net/ipv6/ah6.c:439 (size 16)\n WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439\n\nThe warnings are false positives as the extension headers are\nintentionally placed after the IPv6 header in memory. Fix by properly\ncopying addresses and extension headers separately, and introduce\nhelper functions to avoid code duplication.(CVE-2025-40363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix possible deadlock while configuring policy\n\nFollowing deadlock can be triggered easily by lockdep:\n\nWARNING: possible circular locking dependency detected\n6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted\n------------------------------------------------------\ncheck/1334 is trying to acquire lock:\nff1100011d9d0678 (\u0026amp;q-\u0026gt;sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180\n\nbut task is already holding lock:\nff1100011d9d00e0 (\u0026amp;q-\u0026gt;q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;q-\u0026gt;q_usage_counter(queue)#3){++++}-{0:0}:\n blk_queue_enter+0x40b/0x470\n blkg_conf_prep+0x7b/0x3c0\n tg_set_limit+0x10a/0x3e0\n cgroup_file_write+0xc6/0x420\n kernfs_fop_write_iter+0x189/0x280\n vfs_write+0x256/0x490\n ksys_write+0x83/0x190\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x4608/0x4630\n do_syscall_64+0xdb/0x6b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #1 (\u0026amp;q-\u0026gt;rq_qos_mutex){+.+.}-{4:4}:\n __mutex_lock+0xd8/0xf50\n mutex_lock_nested+0x2b/0x40\n wbt_init+0x17e/0x280\n wbt_enable_default+0xe9/0x140\n blk_register_queue+0x1da/0x2e0\n __add_disk+0x38c/0x5d0\n add_disk_fwnode+0x89/0x250\n device_add_disk+0x18/0x30\n virtblk_probe+0x13a3/0x1800\n virtio_dev_probe+0x389/0x610\n really_probe+0x136/0x620\n __driver_probe_device+0xb3/0x230\n driver_probe_device+0x2f/0xe0\n __driver_attach+0x158/0x250\n bus_for_each_dev+0xa9/0x130\n driver_attach+0x26/0x40\n bus_add_driver+0x178/0x3d0\n driver_register+0x7d/0x1c0\n __register_virtio_driver+0x2c/0x60\n virtio_blk_init+0x6f/0xe0\n do_one_initcall+0x94/0x540\n kernel_init_freeable+0x56a/0x7b0\n kernel_init+0x2b/0x270\n ret_from_fork+0x268/0x4c0\n ret_from_fork_asm+0x1a/0x30\n\n-\u0026gt; #0 (\u0026amp;q-\u0026gt;sysfs_lock){+.+.}-{4:4}:\n __lock_acquire+0x1835/0x2940\n lock_acquire+0xf9/0x450\n __mutex_lock+0xd8/0xf50\n mutex_lock_nested+0x2b/0x40\n blk_unregister_queue+0x53/0x180\n __del_gendisk+0x226/0x690\n del_gendisk+0xba/0x110\n sd_remove+0x49/0xb0 [sd_mod]\n device_remove+0x87/0xb0\n device_release_driver_internal+0x11e/0x230\n device_release_driver+0x1a/0x30\n bus_remove_device+0x14d/0x220\n device_del+0x1e1/0x5a0\n __scsi_remove_device+0x1ff/0x2f0\n scsi_remove_device+0x37/0x60\n sdev_store_delete+0x77/0x100\n dev_attr_store+0x1f/0x40\n sysfs_kf_write+0x65/0x90\n kernfs_fop_write_iter+0x189/0x280\n vfs_write+0x256/0x490\n ksys_write+0x83/0x190\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x4608/0x4630\n do_syscall_64+0xdb/0x6b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nother info that might help us debug this:\n\nChain exists of:\n \u0026amp;q-\u0026gt;sysfs_lock --\u0026gt; \u0026amp;q-\u0026gt;rq_qos_mutex --\u0026gt; \u0026amp;q-\u0026gt;q_usage_counter(queue)#3\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;q-\u0026gt;q_usage_counter(queue)#3);\n lock(\u0026amp;q-\u0026gt;rq_qos_mutex);\n lock(\u0026amp;q-\u0026gt;q_usage_counter(queue)#3);\n lock(\u0026amp;q-\u0026gt;sysfs_lock);\n\nRoot cause is that queue_usage_counter is grabbed with rq_qos_mutex\nheld in blkg_conf_prep(), while queue should be freezed before\nrq_qos_mutex from other context.\n\nThe blk_queue_enter() from blkg_conf_prep() is used to protect against\npolicy deactivation, which is already protected with blkcg_mutex, hence\nconvert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,\nconsider that blkcg_mutex is held after queue is freezed from policy\ndeactivation, also convert blkg_alloc() to use GFP_NOIO.(CVE-2025-68178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Disable AFBC support on Mediatek DRM driver\n\nCommit c410fa9b07c3 (\u0026quot;drm/mediatek: Add AFBC support to Mediatek DRM\ndriver\u0026quot;) added AFBC support to Mediatek DRM and enabled the\n32x8/split/sparse modifier.\n\nHowever, this is currently broken on Mediatek MT8188 (Genio 700 EVK\nplatform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by\ndefault since Mesa v25.0.\n\nKernel trace reports vblank timeouts constantly, and the render is garbled:\n\n```\n[CRTC:62:crtc-0] vblank wait timed out\nWARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\n[...]\nHardware name: MediaTek Genio-700 EVK (DT)\nWorkqueue: events_unbound commit_work\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nlr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nsp : ffff80008337bca0\nx29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000\nx26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000\nx23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80\nx20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a\nx17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000\nx14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b\nx11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70\nx8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70\nx5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480\nCall trace:\n drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)\n drm_atomic_helper_commit_tail_rpm+0x64/0x80\n commit_tail+0xa4/0x1a4\n commit_work+0x14/0x20\n process_one_work+0x150/0x290\n worker_thread+0x2d0/0x3ec\n kthread+0x12c/0x210\n ret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\n```\n\nUntil this gets fixed upstream, disable AFBC support on this platform, as\nit\u0026apos;s currently broken with upstream Mesa.(CVE-2025-68184)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs4_setup_readdir(): insufficient locking for -\u0026gt;d_parent-\u0026gt;d_inode dereferencing\n\nTheoretically it\u0026apos;s an oopsable race, but I don\u0026apos;t believe one can manage\nto hit it on real hardware; might become doable on a KVM, but it still\nwon\u0026apos;t be easy to attack.\n\nAnyway, it\u0026apos;s easy to deal with - since xdr_encode_hyper() is just a call of\nput_unaligned_be64(), we can put that under -\u0026gt;d_lock and be done with that.(CVE-2025-68185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp_tunnel: use netdev_warn() instead of netdev_WARN()\n\nnetdev_WARN() uses WARN/WARN_ON to print a backtrace along with\nfile and line information. In this case, udp_tunnel_nic_register()\nreturning an error is just a failed operation, not a kernel bug.\n\nudp_tunnel_nic_register() can fail due to a memory allocation\nfailure (kzalloc() or udp_tunnel_nic_alloc()).\nThis is a normal runtime error and not a kernel bug.\n\nReplace netdev_WARN() with netdev_warn() accordingly.(CVE-2025-68191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: fix lockdep WARN due to partition scan work\n\nBlktests test cases nvme/014, 057 and 058 fail occasionally due to a\nlockdep WARN. As reported in the Closes tag URL, the WARN indicates that\na deadlock can happen due to the dependency among disk-\u0026gt;open_mutex,\nkblockd workqueue completion and partition_scan_work completion.\n\nTo avoid the lockdep WARN and the potential deadlock, cut the dependency\nby running the partition_scan_work not by kblockd workqueue but by\nnvme_wq.(CVE-2025-68218)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix memory leak in smb3_fs_context_parse_param error path\n\nAdd proper cleanup of ctx-\u0026gt;source and fc-\u0026gt;source to the\ncifs_parse_mount_err error handler. This ensures that memory allocated\nfor the source strings is correctly freed on all error paths, matching\nthe cleanup already performed in the success path by\nsmb3_cleanup_fs_context_contents().\nPointers are also set to NULL after freeing to prevent potential\ndouble-free issues.\n\nThis change fixes a memory leak originally detected by syzbot. The\nleak occurred when processing Opt_source mount options if an error\nhappened after ctx-\u0026gt;source and fc-\u0026gt;source were successfully\nallocated but before the function completed.\n\nThe specific leak sequence was:\n1. ctx-\u0026gt;source = smb3_fs_context_fullpath(ctx, \u0026apos;/\u0026apos;) allocates memory\n2. fc-\u0026gt;source = kstrdup(ctx-\u0026gt;source, GFP_KERNEL) allocates more memory\n3. A subsequent error jumps to cifs_parse_mount_err\n4. The old error handler freed passwords but not the source strings,\ncausing the memory to leak.\n\nThis issue was not addressed by commit e8c73eb7db0a (\u0026quot;cifs: client:\nfix memory leak in smb3_fs_context_parse_param\u0026quot;), which only fixed\nleaks from repeated fsconfig() calls but not this error path.\n\nPatch updated with minor change suggested by kernel test robot(CVE-2025-68219)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()\n\nIf the allocation of tl_hba-\u0026gt;sh fails in tcm_loop_driver_probe() and we\nattempt to dereference it in tcm_loop_tpg_address_show() we will get a\nsegfault, see below for an example. So, check tl_hba-\u0026gt;sh before\ndereferencing it.\n\n Unable to allocate struct scsi_host\n BUG: kernel NULL pointer dereference, address: 0000000000000194\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1\n Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024\n RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]\n...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n configfs_read_iter+0x12d/0x1d0 [configfs]\n vfs_read+0x1b5/0x300\n ksys_read+0x6f/0xf0\n...(CVE-2025-68229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: restore write access before closing files opened by open_exec()\n\nbm_register_write() opens an executable file using open_exec(), which\ninternally calls do_open_execat() and denies write access on the file to\navoid modification while it is being executed.\n\nHowever, when an error occurs, bm_register_write() closes the file using\nfilp_close() directly. This does not restore the write permission, which\nmay cause subsequent write operations on the same file to fail.\n\nFix this by calling exe_file_allow_write_access() before filp_close() to\nrestore the write permission properly.(CVE-2025-68239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe\n\nThe sit driver\u0026apos;s packet transmission path calls: sit_tunnel_xmit() -\u0026gt;\nupdate_or_create_fnhe(), which lead to fnhe_remove_oldest() being called\nto delete entries exceeding FNHE_RECLAIM_DEPTH+random.\n\nThe race window is between fnhe_remove_oldest() selecting fnheX for\ndeletion and the subsequent kfree_rcu(). During this time, the\nconcurrent path\u0026apos;s __mkroute_output() -\u0026gt; find_exception() can fetch the\nsoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a\nnew dst using a dst_hold(). When the original fnheX is freed via RCU,\nthe dst reference remains permanently leaked.\n\nCPU 0 CPU 1\n__mkroute_output()\n find_exception() [fnheX]\n update_or_create_fnhe()\n fnhe_remove_oldest() [fnheX]\n rt_bind_exception() [bind dst]\n RCU callback [fnheX freed, dst leak]\n\nThis issue manifests as a device reference count leak and a warning in\ndmesg when unregistering the net device:\n\n unregister_netdevice: waiting for sitX to become free. Usage count = N\n\nIdo Schimmel provided the simple test validation method [1].\n\nThe fix clears \u0026apos;oldest-\u0026gt;fnhe_daddr\u0026apos; before calling fnhe_flush_routes().\nSince rt_bind_exception() checks this field, setting it to zero prevents\nthe stale fnhe from being reused and bound to a new dst just before it\nis freed.\n\n[1]\nip netns add ns1\nip -n ns1 link set dev lo up\nip -n ns1 address add 192.0.2.1/32 dev lo\nip -n ns1 link add name dummy1 up type dummy\nip -n ns1 route add 192.0.2.2/32 dev dummy1\nip -n ns1 link add name gretap1 up arp off type gretap \\\n local 192.0.2.1 remote 192.0.2.2\nip -n ns1 route add 198.51.0.0/16 dev gretap1\ntaskset -c 0 ip netns exec ns1 mausezahn gretap1 \\\n -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q \u0026amp;\ntaskset -c 2 ip netns exec ns1 mausezahn gretap1 \\\n -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q \u0026amp;\nsleep 10\nip netns pids ns1 | xargs kill\nip netns del ns1(CVE-2025-68241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: netpoll: fix incorrect refcount handling causing incorrect cleanup\n\ncommit efa95b01da18 (\u0026quot;netpoll: fix use after free\u0026quot;) incorrectly\nignored the refcount and prematurely set dev-\u0026gt;npinfo to NULL during\nnetpoll cleanup, leading to improper behavior and memory leaks.\n\nScenario causing lack of proper cleanup:\n\n1) A netpoll is associated with a NIC (e.g., eth0) and netdev-\u0026gt;npinfo is\n allocated, and refcnt = 1\n - Keep in mind that npinfo is shared among all netpoll instances. In\n this case, there is just one.\n\n2) Another netpoll is also associated with the same NIC and\n npinfo-\u0026gt;refcnt += 1.\n - Now dev-\u0026gt;npinfo-\u0026gt;refcnt = 2;\n - There is just one npinfo associated to the netdev.\n\n3) When the first netpolls goes to clean up:\n - The first cleanup succeeds and clears np-\u0026gt;dev-\u0026gt;npinfo, ignoring\n refcnt.\n - It basically calls `RCU_INIT_POINTER(np-\u0026gt;dev-\u0026gt;npinfo, NULL);`\n - Set dev-\u0026gt;npinfo = NULL, without proper cleanup\n - No -\u0026gt;ndo_netpoll_cleanup() is either called\n\n4) Now the second target tries to clean up\n - The second cleanup fails because np-\u0026gt;dev-\u0026gt;npinfo is already NULL.\n * In this case, ops-\u0026gt;ndo_netpoll_cleanup() was never called, and\n the skb pool is not cleaned as well (for the second netpoll\n instance)\n - This leaks npinfo and skbpool skbs, which is clearly reported by\n kmemleak.\n\nRevert commit efa95b01da18 (\u0026quot;netpoll: fix use after free\u0026quot;) and adds\nclarifying comments emphasizing that npinfo cleanup should only happen\nonce the refcount reaches zero, ensuring stable and correct netpoll\nbehavior.(CVE-2025-68245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: avoid infinite loops due to corrupted subpage compact indexes\n\nRobert reported an infinite loop observed by two crafted images.\n\nThe root cause is that `clusterofs` can be larger than `lclustersize`\nfor !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:\n\n blocksize = lclustersize = 512 lcn = 6 clusterofs = 515\n\nMove the corresponding check for full compress indexes to\n`z_erofs_load_lcluster_from_disk()` to also cover subpage compact\ncompress indexes.\n\nIt also fixes the position of `m-\u0026gt;type \u0026gt;= Z_EROFS_LCLUSTER_TYPE_MAX`\ncheck, since it should be placed right after\n`z_erofs_load_{compact,full}_lcluster()`.(CVE-2025-68251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: Fix memory leak in USB bulk transport\n\nA kernel memory leak was identified by the \u0026apos;ioctl_sg01\u0026apos; test from Linux\nTest Project (LTP). The following bytes were mainly observed: 0x53425355.\n\nWhen USB storage devices incorrectly skip the data phase with status data,\nthe code extracts/validates the CSW from the sg buffer, but fails to clear\nit afterwards. This leaves status protocol data in srb\u0026apos;s transfer buffer,\nsuch as the US_BULK_CS_SIGN \u0026apos;USBS\u0026apos; signature observed here. Thus, this can\nlead to USB protocols leaks to user space through SCSI generic (/dev/sg*)\ninterfaces, such as the one seen here when the LTP test requested 512 KiB.\n\nFix the leak by zeroing the CSW data in srb\u0026apos;s transfer buffer immediately\nafter the validation of devices that skip data phase.\n\nNote: Differently from CVE-2018-1000204, which fixed a big leak by zero-\ning pages at allocation time, this leak occurs after allocation, when USB\nprotocol data is written to already-allocated sg pages.(CVE-2025-68288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix memory leak in cifs_construct_tcon()\n\nWhen having a multiuser mount with domain= specified and using\ncifscreds, cifs_set_cifscreds() will end up setting @ctx-\u0026gt;domainname,\nso it needs to be freed before leaving cifs_construct_tcon().\n\nThis fixes the following memory leak reported by kmemleak:\n\n mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...\n su - testuser\n cifscreds add -d ZELDA -u testuser\n ...\n ls /mnt/1\n ...\n umount /mnt\n echo scan \u0026gt; /sys/kernel/debug/kmemleak\n cat /sys/kernel/debug/kmemleak\n unreferenced object 0xffff8881203c3f08 (size 8):\n comm \u0026quot;ls\u0026quot;, pid 5060, jiffies 4307222943\n hex dump (first 8 bytes):\n 5a 45 4c 44 41 00 cc cc ZELDA...\n backtrace (crc d109a8cf):\n __kmalloc_node_track_caller_noprof+0x572/0x710\n kstrdup+0x3a/0x70\n cifs_sb_tlink+0x1209/0x1770 [cifs]\n cifs_get_fattr+0xe1/0xf50 [cifs]\n cifs_get_inode_info+0xb5/0x240 [cifs]\n cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]\n cifs_getattr+0x28e/0x450 [cifs]\n vfs_getattr_nosec+0x126/0x180\n vfs_statx+0xf6/0x220\n do_statx+0xab/0x110\n __x64_sys_statx+0xd5/0x130\n do_syscall_64+0xbb/0x380\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-68295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup\n\nProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOB\naccess in fbcon_remap_all(). Without holding the console lock the call\nraces with switching outputs.\n\nVGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon\nfunction uses struct fb_info.node, which is set by register_framebuffer().\nAs the fb-helper code currently sets up VGA switcheroo before registering\nthe framebuffer, the value of node is -1 and therefore not a legal value.\nFor example, fbcon uses the value within set_con2fb_map() [1] as an index\ninto an array.\n\nMoving vga_switcheroo_client_fb_set() after register_framebuffer() can\nresult in VGA switching that does not switch fbcon correctly.\n\nTherefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),\nwhich already holds the console lock. Fbdev calls fbcon_fb_registered()\nfrom within register_framebuffer(). Serializes the helper with VGA\nswitcheroo\u0026apos;s call to fbcon_remap_all().\n\nAlthough vga_switcheroo_client_fb_set() takes an instance of struct fb_info\nas parameter, it really only needs the contained fbcon state. Moving the\ncall to fbcon initialization is therefore cleaner than before. Only amdgpu,\ni915, nouveau and radeon support vga_switcheroo. For all other drivers,\nthis change does nothing.(CVE-2025-68296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sock: Prevent race in socket write iter and sock bind\n\nThere is a potential race condition between sock bind and socket write\niter. bind may free the same cmd via mgmt_pending before write iter sends\nthe cmd, just as syzbot reported in UAF[1].\n\nHere we use hci_dev_lock to synchronize the two, thereby avoiding the\nUAF mentioned in [1].\n\n[1]\nsyzbot reported:\nBUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316\nRead of size 8 at addr ffff888077164818 by task syz.0.17/5989\nCall Trace:\n mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316\n set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n sock_write_iter+0x279/0x360 net/socket.c:1195\n\nAllocated by task 5989:\n mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296\n set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n sock_write_iter+0x279/0x360 net/socket.c:1195\n\nFreed by task 5991:\n mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]\n mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257\n mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477\n hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump\n\nDo not block PCI config accesses through pci_cfg_access_lock() when\nexecuting the s390 variant of PCI error recovery: Acquire just\ndevice_lock() instead of pci_dev_lock() as powerpc\u0026apos;s EEH and\ngenerig PCI AER processing do.\n\nDuring error recovery testing a pair of tasks was reported to be hung:\n\nmlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working\nINFO: task kmcheck:72 blocked for more than 122 seconds.\n Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000\nCall Trace:\n [\u0026lt;000000065256f030\u0026gt;] __schedule+0x2a0/0x590\n [\u0026lt;000000065256f356\u0026gt;] schedule+0x36/0xe0\n [\u0026lt;000000065256f572\u0026gt;] schedule_preempt_disabled+0x22/0x30\n [\u0026lt;0000000652570a94\u0026gt;] __mutex_lock.constprop.0+0x484/0x8a8\n [\u0026lt;000003ff800673a4\u0026gt;] mlx5_unload_one+0x34/0x58 [mlx5_core]\n [\u0026lt;000003ff8006745c\u0026gt;] mlx5_pci_err_detected+0x94/0x140 [mlx5_core]\n [\u0026lt;0000000652556c5a\u0026gt;] zpci_event_attempt_error_recovery+0xf2/0x398\n [\u0026lt;0000000651b9184a\u0026gt;] __zpci_event_error+0x23a/0x2c0\nINFO: task kworker/u1664:6:1514 blocked for more than 122 seconds.\n Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000\nWorkqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]\nCall Trace:\n [\u0026lt;000000065256f030\u0026gt;] __schedule+0x2a0/0x590\n [\u0026lt;000000065256f356\u0026gt;] schedule+0x36/0xe0\n [\u0026lt;0000000652172e28\u0026gt;] pci_wait_cfg+0x80/0xe8\n [\u0026lt;0000000652172f94\u0026gt;] pci_cfg_access_lock+0x74/0x88\n [\u0026lt;000003ff800916b6\u0026gt;] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core]\n [\u0026lt;000003ff80098824\u0026gt;] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core]\n [\u0026lt;000003ff80074b62\u0026gt;] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core]\n [\u0026lt;0000000652512242\u0026gt;] devlink_health_do_dump.part.0+0x82/0x168\n [\u0026lt;0000000652513212\u0026gt;] devlink_health_report+0x19a/0x230\n [\u0026lt;000003ff80075a12\u0026gt;] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]\n\nNo kernel log of the exact same error with an upstream kernel is\navailable - but the very same deadlock situation can be constructed there,\ntoo:\n\n- task: kmcheck\n mlx5_unload_one() tries to acquire devlink lock while the PCI error\n recovery code has set pdev-\u0026gt;block_cfg_access by way of\n pci_cfg_access_lock()\n- task: kworker\n mlx5_crdump_collect() tries to set block_cfg_access through\n pci_cfg_access_lock() while devlink_health_report() had acquired\n the devlink lock.\n\nA similar deadlock situation can be reproduced by requesting a\ncrdump with\n \u0026gt; devlink health dump show pci/\u0026lt;BDF\u0026gt; reporter fw_fatal\n\nwhile PCI error recovery is executed on the same \u0026lt;BDF\u0026gt; physical function\nby mlx5_core\u0026apos;s pci_error_handlers. On s390 this can be injected with\n \u0026gt; zpcictl --reset-fw \u0026lt;BDF\u0026gt;\n\nTests with this patch failed to reproduce that second deadlock situation,\nthe devlink command is rejected with \u0026quot;kernel answers: Permission denied\u0026quot; -\nand we get a kernel log message of:\n\nmlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5\n\nbecause the config read of VSC_SEMAPHORE is rejected by the underlying\nhardware.\n\nTwo prior attempts to address this issue have been discussed and\nultimately rejected [see link], with the primary argument that s390\u0026apos;s\nimplementation of PCI error recovery is imposing restrictions that\nneither powerpc\u0026apos;s EEH nor PCI AER handling need. Tests show that PCI\nerror recovery on s390 is running to completion even without blocking\naccess to PCI config space.(CVE-2025-68310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Prevents free active kevent\n\nThe root cause of this issue are:\n1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);\nput the kevent work in global workqueue. However, the kevent has not yet\nbeen scheduled when the usbnet device is unregistered. Therefore, executing\nfree_netdev() results in the \u0026quot;free active object (kevent)\u0026quot; error reported\nhere.\n\n2. Another factor is that when calling usbnet_disconnect()-\u0026gt;unregister_netdev(),\nif the usbnet device is up, ndo_stop() is executed to cancel the kevent.\nHowever, because the device is not up, ndo_stop() is not executed.\n\nThe solution to this problem is to cancel the kevent before executing\nfree_netdev().(CVE-2025-68312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config unlock in nbd_genl_connect\n\nThere is one use-after-free warning when running NBD_CMD_CONNECT and\nNBD_CLEAR_SOCK:\n\nnbd_genl_connect\n nbd_alloc_and_init_config // config_refs=1\n nbd_start_device // config_refs=2\n set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3\n recv_work done // config_refs=2\n\t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1\n\t\t\t\t\t\tclose nbd // config_refs=0\n refcount_inc -\u0026gt; uaf\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290\n nbd_genl_connect+0x16d0/0x1ab0\n genl_family_rcv_msg_doit+0x1f3/0x310\n genl_rcv_msg+0x44a/0x790\n\nThe issue can be easily reproduced by adding a small delay before\nrefcount_inc(\u0026amp;nbd-\u0026gt;config_refs) in nbd_genl_connect():\n\n mutex_unlock(\u0026amp;nbd-\u0026gt;config_lock);\n if (!ret) {\n set_bit(NBD_RT_HAS_CONFIG_REF, \u0026amp;config-\u0026gt;runtime_flags);\n+ printk(\u0026quot;before sleep\\n\u0026quot;);\n+ mdelay(5 * 1000);\n+ printk(\u0026quot;after sleep\\n\u0026quot;);\n refcount_inc(\u0026amp;nbd-\u0026gt;config_refs);\n nbd_connect_reply(info, nbd-\u0026gt;index);\n }(CVE-2025-68366)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse\n\nThe following warning appears when running syzkaller, and this issue also\nexists in the mainline code.\n\n ------------[ cut here ]------------\n list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.\n WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130\n Modules linked in:\n CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__list_add_valid_or_report+0xf7/0x130\n RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282\n RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817\n RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001\n RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c\n R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100\n R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48\n FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 80000000\n Call Trace:\n \u0026lt;TASK\u0026gt;\n input_register_handler+0xb3/0x210\n mac_hid_start_emulation+0x1c5/0x290\n mac_hid_toggle_emumouse+0x20a/0x240\n proc_sys_call_handler+0x4c2/0x6e0\n new_sync_write+0x1b1/0x2d0\n vfs_write+0x709/0x950\n ksys_write+0x12a/0x250\n do_syscall_64+0x5a/0x110\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe WARNING occurs when two processes concurrently write to the mac-hid\nemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().\nBoth processes read old_val=0, then both try to register the input handler,\nleading to a double list_add of the same handler.\n\n CPU0 CPU1\n ------------------------- -------------------------\n vfs_write() //write 1 vfs_write() //write 1\n proc_sys_write() proc_sys_write()\n mac_hid_toggle_emumouse() mac_hid_toggle_emumouse()\n old_val = *valp // old_val=0\n old_val = *valp // old_val=0\n mutex_lock_killable()\n proc_dointvec() // *valp=1\n mac_hid_start_emulation()\n input_register_handler()\n mutex_unlock()\n mutex_lock_killable()\n proc_dointvec()\n mac_hid_start_emulation()\n input_register_handler() //Trigger Warning\n mutex_unlock()\n\nFix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: smartpqi: Fix device resources accessed after device removal\n\nCorrect possible race conditions during device removal.\n\nPreviously, a scheduled work item to reset a LUN could still execute\nafter the device was removed, leading to use-after-free and other\nresource access issues.\n\nThis race condition occurs because the abort handler may schedule a LUN\nreset concurrently with device removal via sdev_destroy(), leading to\nuse-after-free and improper access to freed resources.\n\n - Check in the device reset handler if the device is still present in\n the controller\u0026apos;s SCSI device list before running; if not, the reset\n is skipped.\n\n - Cancel any pending TMF work that has not started in sdev_destroy().\n\n - Ensure device freeing in sdev_destroy() is done while holding the\n LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config put in recv_work\n\nThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK and\nNBD_CMD_RECONFIGURE:\n nbd_genl_connect // conf_ref=2 (connect and recv_work A)\n nbd_open\t // conf_ref=3\n recv_work A done // conf_ref=2\n NBD_CLEAR_SOCK // conf_ref=1\n nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)\n close nbd\t // conf_ref=1\n recv_work B\n config_put // conf_ref=0\n atomic_dec(\u0026amp;config-\u0026gt;recv_threads); -\u0026gt; UAF\n\nOr only running NBD_CLEAR_SOCK:\n nbd_genl_connect // conf_ref=2\n nbd_open \t // conf_ref=3\n NBD_CLEAR_SOCK // conf_ref=2\n close nbd\n nbd_release\n config_put // conf_ref=1\n recv_work\n config_put \t // conf_ref=0\n atomic_dec(\u0026amp;config-\u0026gt;recv_threads); -\u0026gt; UAF\n\nCommit 87aac3a80af5 (\u0026quot;nbd: call nbd_config_put() before notifying the\nwaiter\u0026quot;) moved nbd_config_put() to run before waking up the waiter in\nrecv_work, in order to ensure that nbd_start_device_ioctl() would not\nbe woken up while nbd-\u0026gt;task_recv was still uncleared.\n\nHowever, in nbd_start_device_ioctl(), after being woken up it explicitly\ncalls flush_workqueue() to make sure all current works are finished.\nTherefore, there is no need to move the config put ahead of the wakeup.\n\nMove nbd_config_put() to the end of recv_work, so that the reference is\nheld for the whole lifetime of the worker thread. This makes sure the\nconfig cannot be freed while recv_work is still running, even if clear\n+ reconfigure interleave.\n\nIn addition, we don\u0026apos;t need to worry about recv_work dropping the last\nnbd_put (which causes deadlock):\n\npath A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):\n connect // nbd_refs=1 (trigger recv_work)\n open nbd // nbd_refs=2\n NBD_CLEAR_SOCK\n close nbd\n nbd_release\n nbd_disconnect_and_put\n flush_workqueue // recv_work done\n nbd_config_put\n nbd_put // nbd_refs=1\n nbd_put // nbd_refs=0\n queue_work\n\npath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):\n connect // nbd_refs=2 (trigger recv_work)\n open nbd // nbd_refs=3\n NBD_CLEAR_SOCK // conf_refs=2\n close nbd\n nbd_release\n nbd_config_put // conf_refs=1\n nbd_put // nbd_refs=2\n recv_work done // conf_refs=0, nbd_refs=1\n rmmod // nbd_refs=0\n\nDepends-on: e2daec488c57 (\u0026quot;nbd: Fix hungtask when nbd_config_put\u0026quot;)(CVE-2025-68372)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix rcu protection in md_wakeup_thread\n\nWe attempted to use RCU to protect the pointer \u0026apos;thread\u0026apos;, but directly\npassed the value when calling md_wakeup_thread(). This means that the\nRCU pointer has been acquired before rcu_read_lock(), which renders\nrcu_read_lock() ineffective and could lead to a use-after-free.(CVE-2025-68374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix null deref on srq-\u0026gt;rq.queue after resize failure\n\nA NULL pointer dereference can occur in rxe_srq_chk_attr() when\nibv_modify_srq() is invoked twice in succession under certain error\nconditions. The first call may fail in rxe_queue_resize(), which leads\nrxe_srq_from_attr() to set srq-\u0026gt;rq.queue = NULL. The second call then\ntriggers a crash (null deref) when accessing\nsrq-\u0026gt;rq.queue-\u0026gt;buf-\u0026gt;index_mask.\n\nCall Trace:\n\u0026lt;TASK\u0026gt;\nrxe_modify_srq+0x170/0x480 [rdma_rxe]\n? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]\n? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]\n? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]\nib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]\n? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]\n? tryinc_node_nr_active+0xe6/0x150\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\nib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]\n? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]\n? __pfx___raw_spin_lock_irqsave+0x10/0x10\n? __pfx_do_vfs_ioctl+0x10/0x10\n? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0\n? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10\nib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]\n? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]\n__x64_sys_ioctl+0x138/0x1c0\ndo_syscall_64+0x82/0x250\n? fdget_pos+0x58/0x4c0\n? ksys_write+0xf3/0x1c0\n? __pfx_ksys_write+0x10/0x10\n? do_syscall_64+0xc8/0x250\n? __pfx_vm_mmap_pgoff+0x10/0x10\n? fget+0x173/0x230\n? fput+0x2a/0x80\n? ksys_mmap_pgoff+0x224/0x4c0\n? do_syscall_64+0xc8/0x250\n? do_user_addr_fault+0x37b/0xfe0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-68379)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags\n\nWhen a filesystem is being automounted, it needs to preserve the\nuser-set superblock mount options, such as the \u0026quot;ro\u0026quot; flag.(CVE-2025-68764)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfsnotify: do not generate ACCESS/MODIFY events on child for special files\n\ninotify/fanotify do not allow users with no read access to a file to\nsubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the\nsame user to subscribe for watching events on children when the user\nhas access to the parent directory (e.g. /dev).\n\nUsers with no read access to a file but with read access to its parent\ndirectory can still stat the file and see if it was accessed/modified\nvia atime/mtime change.\n\nThe same is not true for special files (e.g. /dev/null). Users will not\ngenerally observe atime/mtime changes when other users read/write to\nspecial files, only when someone sets atime/mtime via utimensat().\n\nAlign fsnotify events with this stat behavior and do not generate\nACCESS/MODIFY events to parent watchers on read/write of special files.\nThe events are still generated to parent watchers on utimensat(). This\ncloses some side-channels that could be possibly used for information\nexfiltration [1].\n\n[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: missing copy_finish in fuse-over-io-uring argument copies\n\nFix a possible reference count leak of payload pages during\nfuse argument copies.\n\n[Joanne: simplified error cleanup](CVE-2025-68791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd: Check event before enable to avoid GPF\n\nOn AMD machines cpuc-\u0026gt;events[idx] can become NULL in a subtle race\ncondition with NMI-\u0026gt;throttle-\u0026gt;x86_pmu_stop().\n\nCheck event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.\nThis appears to be an AMD only issue.\n\nSyzkaller reported a GPF in amd_pmu_enable_all.\n\nINFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143\n msecs\nOops: general protection fault, probably for non-canonical address\n 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]\nCPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk\nRIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195\n arch/x86/events/core.c:1430)\nRSP: 0018:ffff888118009d60 EFLAGS: 00010012\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002\nR13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601\nFS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\namd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))\nx86_pmu_enable (arch/x86/events/core.c:1360)\nevent_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186\n kernel/events/core.c:2346)\n__perf_remove_from_context (kernel/events/core.c:2435)\nevent_function (kernel/events/core.c:259)\nremote_function (kernel/events/core.c:92 (discriminator 1)\n kernel/events/core.c:72 (discriminator 1))\n__flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27\n ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64\n kernel/smp.c:135 kernel/smp.c:540)\n__sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27\n ./include/linux/jump_label.h:207\n ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)\nsysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)\n arch/x86/kernel/smp.c:266 (discriminator 47))\n \u0026lt;/IRQ\u0026gt;(CVE-2025-68798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats\n\nCited commit added a dedicated mutex (instead of RTNL) to protect the\nmulticast route list, so that it will not change while the driver\nperiodically traverses it in order to update the kernel about multicast\nroute stats that were queried from the device.\n\nOne instance of list entry deletion (during route replace) was missed\nand it can result in a use-after-free [1].\n\nFix by acquiring the mutex before deleting the entry from the list and\nreleasing it afterwards.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]\nRead of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043\n\nCPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)\nHardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017\nWorkqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xba/0x110\n print_report+0x174/0x4f5\n kasan_report+0xdf/0x110\n mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 29933:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]\n mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30\n\nFreed by task 29933:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x70\n __kasan_slab_free+0x43/0x70\n kfree+0x14e/0x700\n mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]\n mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30(CVE-2025-68800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix neighbour use-after-free\n\nWe sometimes observe use-after-free when dereferencing a neighbour [1].\nThe problem seems to be that the driver stores a pointer to the\nneighbour, but without holding a reference on it. A reference is only\ntaken when the neighbour is used by a nexthop.\n\nFix by simplifying the reference counting scheme. Always take a\nreference when storing a neighbour pointer in a neighbour entry. Avoid\ntaking a referencing when the neighbour is used by a nexthop as the\nneighbour entry associated with the nexthop already holds a reference.\n\nTested by running the test that uncovered the problem over 300 times.\nWithout this patch the problem was reproduced after a handful of\niterations.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310\nRead of size 8 at addr ffff88817f8e3420 by task ip/3929\n\nCPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6e/0x300\n print_report+0xfc/0x1fb\n kasan_report+0xe4/0x110\n mlxsw_sp_neigh_entry_update+0x2d4/0x310\n mlxsw_sp_router_rif_gone_sync+0x35f/0x510\n mlxsw_sp_rif_destroy+0x1ea/0x730\n mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0\n __mlxsw_sp_inetaddr_lag_event+0xcc/0x130\n __mlxsw_sp_inetaddr_event+0xf5/0x3c0\n mlxsw_sp_router_netdevice_event+0x1015/0x1580\n notifier_call_chain+0xcc/0x150\n call_netdevice_notifiers_info+0x7e/0x100\n __netdev_upper_dev_unlink+0x10b/0x210\n netdev_upper_dev_unlink+0x79/0xa0\n vrf_del_slave+0x18/0x50\n do_set_master+0x146/0x7d0\n do_setlink.isra.0+0x9a0/0x2880\n rtnl_newlink+0x637/0xb20\n rtnetlink_rcv_msg+0x6fe/0xb90\n netlink_rcv_skb+0x123/0x380\n netlink_unicast+0x4a3/0x770\n netlink_sendmsg+0x75b/0xc90\n __sock_sendmsg+0xbe/0x160\n ____sys_sendmsg+0x5b2/0x7d0\n ___sys_sendmsg+0xfd/0x180\n __sys_sendmsg+0x124/0x1c0\n do_syscall_64+0xbb/0xfd0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[...]\n\nAllocated by task 109:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x2c1/0x790\n neigh_alloc+0x6af/0x8f0\n ___neigh_create+0x63/0xe90\n mlxsw_sp_nexthop_neigh_init+0x430/0x7e0\n mlxsw_sp_nexthop_type_init+0x212/0x960\n mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280\n mlxsw_sp_nexthop6_group_get+0x392/0x6a0\n mlxsw_sp_fib6_entry_create+0x46a/0xfd0\n mlxsw_sp_router_fib6_replace+0x1ed/0x5f0\n mlxsw_sp_router_fib6_event_work+0x10a/0x2a0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nFreed by task 154:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x43/0x70\n kmem_cache_free_bulk.part.0+0x1eb/0x5e0\n kvfree_rcu_bulk+0x1f2/0x260\n kfree_rcu_work+0x130/0x1b0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nLast potentially related work creation:\n kasan_save_stack+0x30/0x50\n kasan_record_aux_stack+0x8c/0xa0\n kvfree_call_rcu+0x93/0x5b0\n mlxsw_sp_router_neigh_event_work+0x67d/0x860\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20(CVE-2025-68801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix io-uring list corruption for terminated non-committed requests\n\nWhen a request is terminated before it has been committed, the request\nis not removed from the queue\u0026apos;s list. This leaves a dangling list entry\nthat leads to list corruption and use-after-free issues.\n\nRemove the request from the queue\u0026apos;s list for terminated non-committed\nrequests.(CVE-2025-68805)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix readahead reclaim deadlock\n\nCommit e26ee4efbc79 (\u0026quot;fuse: allocate ff-\u0026gt;release_args only if release is\nneeded\u0026quot;) skips allocating ff-\u0026gt;release_args if the server does not\nimplement open. However in doing so, fuse_prepare_release() now skips\ngrabbing the reference on the inode, which makes it possible for an\ninode to be evicted from the dcache while there are inflight readahead\nrequests. This causes a deadlock if the server triggers reclaim while\nservicing the readahead request and reclaim attempts to evict the inode\nof the file being read ahead. Since the folio is locked during\nreadahead, when reclaim evicts the fuse inode and fuse_evict_inode()\nattempts to remove all folios associated with the inode from the page\ncache (truncate_inode_pages_range()), reclaim will block forever waiting\nfor the lock since readahead cannot relinquish the lock because it is\nitself blocked in reclaim:\n\n\u0026gt;\u0026gt;\u0026gt; stack_trace(1504735)\n folio_wait_bit_common (mm/filemap.c:1308:4)\n folio_lock (./include/linux/pagemap.h:1052:3)\n truncate_inode_pages_range (mm/truncate.c:336:10)\n fuse_evict_inode (fs/fuse/inode.c:161:2)\n evict (fs/inode.c:704:3)\n dentry_unlink_inode (fs/dcache.c:412:3)\n __dentry_kill (fs/dcache.c:615:3)\n shrink_kill (fs/dcache.c:1060:12)\n shrink_dentry_list (fs/dcache.c:1087:3)\n prune_dcache_sb (fs/dcache.c:1168:2)\n super_cache_scan (fs/super.c:221:10)\n do_shrink_slab (mm/shrinker.c:435:9)\n shrink_slab (mm/shrinker.c:626:10)\n shrink_node (mm/vmscan.c:5951:2)\n shrink_zones (mm/vmscan.c:6195:3)\n do_try_to_free_pages (mm/vmscan.c:6257:3)\n do_swap_page (mm/memory.c:4136:11)\n handle_pte_fault (mm/memory.c:5562:10)\n handle_mm_fault (mm/memory.c:5870:9)\n do_user_addr_fault (arch/x86/mm/fault.c:1338:10)\n handle_page_fault (arch/x86/mm/fault.c:1481:3)\n exc_page_fault (arch/x86/mm/fault.c:1539:2)\n asm_exc_page_fault+0x22/0x27\n\nFix this deadlock by allocating ff-\u0026gt;release_args and grabbing the\nreference on the inode when preparing the file for release even if the\nserver does not implement open. The inode reference will be dropped when\nthe last reference on the fuse file is dropped (see fuse_file_put() -\u0026gt;\nfuse_release_end()).(CVE-2025-68821)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\u0026quot;i40evf: Allow PF driver to configure RSS\u0026quot;),\nthe loop upper bounds were:\n i \u0026lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u0026lt;= adapter-\u0026gt;rss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u0026lt;=`\naccesses one element past the end.\n\nFix the issues by using `\u0026lt;` instead of `\u0026lt;=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u0026gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000: fix OOB in e1000_tbi_should_accept()\n\nIn e1000_tbi_should_accept() we read the last byte of the frame via\n\u0026apos;data[length - 1]\u0026apos; to evaluate the TBI workaround. If the descriptor-\nreported length is zero or larger than the actual RX buffer size, this\nread goes out of bounds and can hit unrelated slab objects. The issue\nis observed from the NAPI receive path (e1000_clean_rx_irq):\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790\nRead of size 1 at addr ffff888014114e54 by task sshd/363\n\nCPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x5a/0x74\n print_address_description+0x7b/0x440\n print_report+0x101/0x200\n kasan_report+0xc1/0xf0\n e1000_tbi_should_accept+0x610/0x790\n e1000_clean_rx_irq+0xa8c/0x1110\n e1000_clean+0xde2/0x3c10\n __napi_poll+0x98/0x380\n net_rx_action+0x491/0xa20\n __do_softirq+0x2c9/0x61d\n do_softirq+0xd1/0x120\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0xfe/0x130\n ip_finish_output2+0x7d5/0xb00\n __ip_queue_xmit+0xe24/0x1ab0\n __tcp_transmit_skb+0x1bcb/0x3340\n tcp_write_xmit+0x175d/0x6bd0\n __tcp_push_pending_frames+0x7b/0x280\n tcp_sendmsg_locked+0x2e4f/0x32d0\n tcp_sendmsg+0x24/0x40\n sock_write_iter+0x322/0x430\n vfs_write+0x56c/0xa60\n ksys_write+0xd1/0x190\n do_syscall_64+0x43/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f511b476b10\nCode: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24\nRSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10\nRDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003\nRBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00\nR10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003\n \u0026lt;/TASK\u0026gt;\nAllocated by task 1:\n __kasan_krealloc+0x131/0x1c0\n krealloc+0x90/0xc0\n add_sysfs_param+0xcb/0x8a0\n kernel_add_sysfs_param+0x81/0xd4\n param_sysfs_builtin+0x138/0x1a6\n param_sysfs_init+0x57/0x5b\n do_one_initcall+0x104/0x250\n do_initcall_level+0x102/0x132\n do_initcalls+0x46/0x74\n kernel_init_freeable+0x28f/0x393\n kernel_init+0x14/0x1a0\n ret_from_fork+0x22/0x30\nThe buggy address belongs to the object at ffff888014114000\n which belongs to the cache kmalloc-2k of size 2048\nThe buggy address is located 1620 bytes to the right of\n 2048-byte region [ffff888014114000, ffff888014114800]\nThe buggy address belongs to the physical page:\npage:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110\nhead:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0\nflags: 0x100000000010200(slab|head|node=0|zone=1)\nraw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000\nraw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n==================================================================\n\nThis happens because the TBI check unconditionally dereferences the last\nbyte without validating the reported length first:\n\n\tu8 last_byte = *(data + length - 1);\n\nFix by rejecting the frame early if the length is zero, or if it exceeds\nadapter-\u0026gt;rx_buffer_len. This preserves the TBI workaround semantics for\nvalid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: Handle incorrect num_connectors capability\n\nThe UCSI spec states that the num_connectors field is 7 bits, and the\n8th bit is reserved and should be set to zero.\nSome buggy FW has been known to set this bit, and it can lead to a\nsystem not booting.\nFlag that the FW is not behaving correctly, and auto-fix the value\nso that the system boots correctly.\n\nFound on Lenovo P1 G8 during Linux enablement program. The FW will\nbe fixed, but seemed worth addressing in case it hit platforms that\naren\u0026apos;t officially Linux supported.(CVE-2025-71108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - zero initialize memory allocated via sock_kmalloc\n\nSeveral crypto user API contexts and requests allocated with\nsock_kmalloc() were left uninitialized, relying on callers to\nset fields explicitly. This resulted in the use of uninitialized\ndata in certain error paths or when new fields are added in the\nfuture.\n\nThe ACVP patches also contain two user-space interface files:\nalgif_kpp.c and algif_akcipher.c. These too rely on proper\ninitialization of their context structures.\n\nA particular issue has been observed with the newly added\n\u0026apos;inflight\u0026apos; variable introduced in af_alg_ctx by commit:\n\n 67b164a871af (\u0026quot;crypto: af_alg - Disallow multiple in-flight AIO requests\u0026quot;)\n\nBecause the context is not memset to zero after allocation,\nthe inflight variable has contained garbage values. As a result,\naf_alg_alloc_areq() has incorrectly returned -EBUSY randomly when\nthe garbage value was interpreted as true:\n\n https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209\n\nThe check directly tests ctx-\u0026gt;inflight without explicitly\ncomparing against true/false. Since inflight is only ever set to\ntrue or false later, an uninitialized value has triggered\n-EBUSY failures. Zero-initializing memory allocated with\nsock_kmalloc() ensures inflight and other fields start in a known\nstate, removing random issues caused by uninitialized data.(CVE-2025-71113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/kexec: Enable SMT before waking offline CPUs\n\nIf SMT is disabled or a partial SMT state is enabled, when a new kernel\nimage is loaded for kexec, on reboot the following warning is observed:\n\nkexec: Waking offline cpu 228.\nWARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc\n[snip]\n NIP kexec_prepare_cpus+0x1b0/0x1bc\n LR kexec_prepare_cpus+0x1a0/0x1bc\n Call Trace:\n kexec_prepare_cpus+0x1a0/0x1bc (unreliable)\n default_machine_kexec+0x160/0x19c\n machine_kexec+0x80/0x88\n kernel_kexec+0xd0/0x118\n __do_sys_reboot+0x210/0x2c4\n system_call_exception+0x124/0x320\n system_call_vectored_common+0x15c/0x2ec\n\nThis occurs as add_cpu() fails due to cpu_bootable() returning false for\nCPUs that fail the cpu_smt_thread_allowed() check or non primary\nthreads if SMT is disabled.\n\nFix the issue by enabling SMT and resetting the number of SMT threads to\nthe number of threads per core, before attempting to wake up all present\nCPUs.(CVE-2025-71119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not register unsupported perf events\n\nSynthetic events currently do not have a function to register perf events.\nThis leads to calling the tracepoint register functions with a NULL\nfunction pointer which triggers:\n\n ------------[ cut here ]------------\n WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:tracepoint_add_func+0x357/0x370\n Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc \u0026lt;0f\u0026gt; 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f\n RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246\n RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000\n RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8\n RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780\n R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a\n R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78\n FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register+0x5d/0x90\n synth_event_reg+0x3c/0x60\n perf_trace_event_init+0x204/0x340\n perf_trace_init+0x85/0xd0\n perf_tp_event_init+0x2e/0x50\n perf_try_init_event+0x6f/0x230\n ? perf_event_alloc+0x4bb/0xdc0\n perf_event_alloc+0x65a/0xdc0\n __se_sys_perf_event_open+0x290/0x9f0\n do_syscall_64+0x93/0x7b0\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? trace_hardirqs_off+0x53/0xc0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInstead, have the code return -ENODEV, which doesn\u0026apos;t warn and has perf\nerror out with:\n\n # perf record -e synthetic:futex_wait\nError:\nThe sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).\n\u0026quot;dmesg | grep -i perf\u0026quot; may provide additional information.\n\nIdeally perf should support synthetic events, but for now just fix the\nwarning. The support can come later.(CVE-2025-71125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix memory and information leak in smb3_reconfigure()\n\nIn smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the\nfunction returns immediately without freeing and erasing the newly\nallocated new_password and new_password2. This causes both a memory leak\nand a potential information leak.\n\nFix this by calling kfree_sensitive() on both password buffers before\nreturning in this error case.(CVE-2025-71151)",
"id": "OESA-2026-1305",
"modified": "2026-08-06T11:10:20Z",
"published": "2026-02-06T11:10:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38110"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38162"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38208"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38457"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38712"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40252"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40264"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40268"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40311"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40314"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40328"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40345"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40360"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40363"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68185"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68191"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68218"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68219"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68251"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68295"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68296"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68367"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68371"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68372"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68374"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68379"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68764"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68788"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71113"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71151"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-57994",
"CVE-2024-58012",
"CVE-2025-37800",
"CVE-2025-38110",
"CVE-2025-38111",
"CVE-2025-38149",
"CVE-2025-38162",
"CVE-2025-38208",
"CVE-2025-38232",
"CVE-2025-38244",
"CVE-2025-38342",
"CVE-2025-38393",
"CVE-2025-38455",
"CVE-2025-38457",
"CVE-2025-38688",
"CVE-2025-38697",
"CVE-2025-38712",
"CVE-2025-38713",
"CVE-2025-38714",
"CVE-2025-38728",
"CVE-2025-39720",
"CVE-2025-39730",
"CVE-2025-39737",
"CVE-2025-39798",
"CVE-2025-39823",
"CVE-2025-39828",
"CVE-2025-39839",
"CVE-2025-39927",
"CVE-2025-39929",
"CVE-2025-39951",
"CVE-2025-39994",
"CVE-2025-40058",
"CVE-2025-40087",
"CVE-2025-40099",
"CVE-2025-40103",
"CVE-2025-40111",
"CVE-2025-40250",
"CVE-2025-40252",
"CVE-2025-40259",
"CVE-2025-40261",
"CVE-2025-40264",
"CVE-2025-40268",
"CVE-2025-40273",
"CVE-2025-40284",
"CVE-2025-40304",
"CVE-2025-40311",
"CVE-2025-40314",
"CVE-2025-40319",
"CVE-2025-40320",
"CVE-2025-40322",
"CVE-2025-40324",
"CVE-2025-40328",
"CVE-2025-40345",
"CVE-2025-40350",
"CVE-2025-40360",
"CVE-2025-40363",
"CVE-2025-68178",
"CVE-2025-68184",
"CVE-2025-68185",
"CVE-2025-68191",
"CVE-2025-68218",
"CVE-2025-68219",
"CVE-2025-68229",
"CVE-2025-68239",
"CVE-2025-68241",
"CVE-2025-68245",
"CVE-2025-68251",
"CVE-2025-68288",
"CVE-2025-68295",
"CVE-2025-68296",
"CVE-2025-68305",
"CVE-2025-68310",
"CVE-2025-68312",
"CVE-2025-68366",
"CVE-2025-68367",
"CVE-2025-68371",
"CVE-2025-68372",
"CVE-2025-68374",
"CVE-2025-68379",
"CVE-2025-68764",
"CVE-2025-68788",
"CVE-2025-68791",
"CVE-2025-68798",
"CVE-2025-68800",
"CVE-2025-68801",
"CVE-2025-68805",
"CVE-2025-68821",
"CVE-2025-71087",
"CVE-2025-71093",
"CVE-2025-71108",
"CVE-2025-71113",
"CVE-2025-71119",
"CVE-2025-71125",
"CVE-2025-71151"
]
}
OESA-2026-2582 (CVE-2025-39833)
Vulnerability from osv_openeuler – Published: 2026-06-05 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
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:
mlxsw: spectrum_router: Fix neighbour use-after-free
We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.
Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.
Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929
CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 _syssendmsg+0x5b2/0x7d0 _sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [...]
Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20(CVE-2025-68801)
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: bound check rq_pages index in inline path
svc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without verifying rc_curpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.(CVE-2025-71068)
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix off-by-one issues in iavf_config_rss_reg()
There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX which is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4
where rss_{key,lut}_size / 4 is the number of dwords, so the last
valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <=
accesses one element past the end.
Fix the issues by using < instead of <=, ensuring we do not exceed
the bounds.
[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)
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:
net: dsa: properly keep track of conduit reference
Problem description
DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.
There are two distinct problems.
- The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:
(unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind
we see these lines in the output diff which appear only with the patch applied:
kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)
- After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).
Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.
So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.
Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.
As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.
History and blame attribution
The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.
We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---(CVE-2025-71152)
In the Linux kernel, the following vulnerability has been resolved:
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:
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:
ipv4: ip_gre: make ipgre_header() robust
Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")
Over the years, syzbot found many ways to crash the kernel in ipgre_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 ipgre device.
[1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: <TASK> skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 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 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246(CVE-2026-23011)
In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: prevent pcp corruption with SMP=n
The kernel test robot has reported:
BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: <IRQ> __dump_stack (lib/dump_stack.c:95) dump_stack_lvl (lib/dump_stack.c:123) dump_stack (lib/dump_stack.c:130) spin_dump (kernel/locking/spinlock_debug.c:71) do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?) _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138) __free_frozen_pages (mm/page_alloc.c:2973) freepages (mm/page_alloc.c:5295) free_pages (mm/page_alloc.c:5334) tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290) ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289) ? rcu_core (kernel/rcu/tree.c:?) rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcu_core_si (kernel/rcu/tree.c:2879) handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725) irq_exit_rcu (kernel/softirq.c:741) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052) </IRQ> <TASK> RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194) free_pcppages_bulk (mm/page_alloc.c:1494) drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632) __drain_all_pages (mm/page_alloc.c:2731) drain_all_pages (mm/page_alloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork (arch/x86/kernel/process.c:164) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) </TASK>
Matthew has analyzed the report and identified that in drain_page_zone() we are in a section protected by spin_lock(&pcp->lock) and then get an interrupt that attempts spin_trylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spin_trylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure.
The problem has been introduced by commit 574907741599 ("mm/page_alloc: leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spin_trylock() sections on SMP=n, but the need to prevent the nesting in spin_lock() has not been recognized. Fix it by introducing local wrappers that change the spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places that do spin_lock(&pcp->lock).
[(CVE-2026-23025)
In the Linux kernel, the following vulnerability has been resolved:
net: hv_netvsc: reject RSS hash key programming without RX indirection table
RSS configuration requires a valid RX indirection table. When the device reports a single receive queue, rndis_filter_device_add() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang.
Fix this by gating netvsc_set_rxfh() on ndc->rx_table_sz and return -EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device capabilities and prevents incorrect behavior.(CVE-2026-23054)
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:
mm/hugetlb: fix hugetlb_pmd_shared()
Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)", v3.
One functional fix, one performance regression fix, and two related comment fixes.
I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things.
The goal of this patch set is to be backported to stable trees "fairly" easily. At least patch #1 and #4.
Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit().
The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated
There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series.
Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86.
This patch (of 4):
We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing.
We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table.
Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface.
Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().(CVE-2026-23100)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add recursion protection in kernel stack trace recording
A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again.
Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI).
Have the stack trace code use the interrupt context to protect against recursion.
Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately.(CVE-2026-23138)
In the Linux kernel, the following vulnerability has been resolved:
tcp: secure_seq: add back ports to TS offset
This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")
tcp_tw_recycle went away in 2017.
Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways.
One of them is to bring back TCP ports in TS offset randomization.
As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset.(CVE-2026-23247)
In the Linux kernel, a vulnerability exists in the AppArmor module's unpack_pdb function. The vulnerability occurs due to failure to validate that DFA start states are within bounds, which can lead to out-of-bound reads. An attacker can exploit this vulnerability through specially crafted policy files, potentially leading to information disclosure or system crashes.(CVE-2026-23269)
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/sched: act_ife: Fix metalist update behavior
Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op:
[ 138.423369][ C1] ================================================================== [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255 [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 138.425800][ C1] Call Trace: [ 138.425804][ C1] <IRQ> [ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122) [ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1)) [ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1)) [ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2)) [ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171) [ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57) [ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114) [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45) [ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)
To solve this issue, fix the replace behavior by adding the metalist to the ife rcu data structure.(CVE-2026-23378)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix memory leak in ice_set_ringparam()
In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings.
Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails.
Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix side-effect bug in match_char() macro usage
The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary.
[ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976
[ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] <TASK> [ 94.986347] dump_stack_lvl+0x5e/0x80 [ 94.986374] print_report+0xc8/0x270 [ 94.986384] ? aa_dfa_match+0x5ae/0x760 [ 94.986388] kasan_report+0x118/0x150 [ 94.986401] ? aa_dfa_match+0x5ae/0x760 [ 94.986405] aa_dfa_match+0x5ae/0x760 [ 94.986408] __aa_path_perm+0x131/0x400 [ 94.986418] aa_path_perm+0x219/0x2f0 [ 94.986424] apparmor_file_open+0x345/0x570 [ 94.986431] security_file_open+0x5c/0x140 [ 94.986442] do_dentry_open+0x2f6/0x1120 [ 94.986450] vfs_open+0x38/0x2b0 [ 94.986453] ? may_open+0x1e2/0x2b0 [ 94.986466] path_openat+0x231b/0x2b30 [ 94.986469] ? __x64_sys_openat+0xf8/0x130 [ 94.986477] do_file_open+0x19d/0x360 [ 94.986487] do_sys_openat2+0x98/0x100 [ 94.986491] __x64_sys_openat+0xf8/0x130 [ 94.986499] do_syscall_64+0x8e/0x660 [ 94.986515] ? count_memcg_events+0x15f/0x3c0 [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0 [ 94.986551] ? vma_start_read+0xf0/0x320 [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0 [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0 [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986588] ? irqentry_exit+0x3c/0x590 [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea
Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop.(CVE-2026-23406)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix missing bounds check on DEFAULT table in verify_dfa()
The verify_dfa() function only checks DEFAULT_TABLE bounds when the state is not differentially encoded.
When the verification loop traverses the differential encoding chain, it reads k = DEFAULT_TABLE[j] and uses k as an array index without validation. A malformed DFA with DEFAULT_TABLE[j] >= state_count, therefore, causes both out-of-bounds reads and writes.
[ 57.179855] ================================================================== [ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660 [ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993
[ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 57.181563] Call Trace: [ 57.181572] <TASK> [ 57.181577] dump_stack_lvl+0x5e/0x80 [ 57.181596] print_report+0xc8/0x270 [ 57.181605] ? verify_dfa+0x59a/0x660 [ 57.181608] kasan_report+0x118/0x150 [ 57.181620] ? verify_dfa+0x59a/0x660 [ 57.181623] verify_dfa+0x59a/0x660 [ 57.181627] aa_dfa_unpack+0x1610/0x1740 [ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470 [ 57.181640] unpack_pdb+0x86d/0x46b0 [ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181656] ? aa_unpack_nameX+0x1a8/0x300 [ 57.181659] aa_unpack+0x20b0/0x4c30 [ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181664] ? stack_depot_save_flags+0x33/0x700 [ 57.181681] ? kasan_save_track+0x4f/0x80 [ 57.181683] ? kasan_save_track+0x3e/0x80 [ 57.181686] ? __kasan_kmalloc+0x93/0xb0 [ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130 [ 57.181697] ? policy_update+0x154/0x330 [ 57.181704] aa_replace_profiles+0x15a/0x1dd0 [ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181712] ? aa_loaddata_alloc+0x77/0x140 [ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181717] ? _copy_from_user+0x2a/0x70 [ 57.181730] policy_update+0x17a/0x330 [ 57.181733] profile_replace+0x153/0x1a0 [ 57.181735] ? rw_verify_area+0x93/0x2d0 [ 57.181740] vfs_write+0x235/0xab0 [ 57.181745] ksys_write+0xb0/0x170 [ 57.181748] do_syscall_64+0x8e/0x660 [ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 57.181765] RIP: 0033:0x7f6192792eb2
Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE entries unconditionally.(CVE-2026-23407)
A race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)
A vulnerability exists in the AppArmor security module of the Linux kernel when handling the i_private field of the inode structure. AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor's access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)
In the Linux kernel, the following vulnerability has been resolved:
udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n
When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference.
The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: <TASK> genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)
This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.(CVE-2026-23439)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix race condition during IPSec ESN update
In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esn_event_arm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esn_event_arm back to 0x1.
A race condition exists in this handling path. After validating the event, the driver calls mlx5_accel_esp_modify_xfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock.
So, need to acknowledge the event first by setting esn_event_arm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished.
Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic.
Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5_accel_esp_modify_xfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.(CVE-2026-23440)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent concurrent access to IPSec ASO context
The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5e_ipsec_aso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.
A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.
When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.
This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.(CVE-2026-23441)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure
ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do.
Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free.
Document the skb ownership guarantee in the function's kdoc.(CVE-2026-23444)
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)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()
Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].
smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release().
This leads to two issues:
1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed.
The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race):
CPU A (softirq) CPU B (process ctx)
tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) / No lock on listener / smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash!
Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed.
Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight.
- Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock().
- Use rcu_read_lock() to protect reading sk_user_data.
- Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.
Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected.
Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied.
[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9(CVE-2026-23450)
In the Linux kernel, the following vulnerability has been resolved:
PM: runtime: Fix a race condition related to device removal
The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed:
/* Maybe the parent is now able to suspend. */
if (parent && !parent->power.ignore_children) {
spin_unlock(&dev->power.lock);
spin_lock(&parent->power.lock);
rpm_idle(parent, RPM_ASYNC);
spin_unlock(&parent->power.lock);
spin_lock(&dev->power.lock);
}
Fix this by inserting a flush_work() call in pm_runtime_remove().
Without this patch blktest block/001 triggers the following complaint sporadically:
BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: <TASK> dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 </TASK>
Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810(CVE-2026-23452)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user
After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del"), l2cap_conn_del() uses conn->lock to protect access to conn->users. However, l2cap_register_user() and l2cap_unregister_user() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2cap_conn_del().
This can lead to use-after-free and list corruption bugs, as reported by syzbot.
Fix this by changing l2cap_register_user() and l2cap_unregister_user() to use conn->lock instead of hci_dev_lock(), ensuring consistent locking for the l2cap_conn structure.(CVE-2026-23461)
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:
spi: fix statistics allocation
The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.
Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).(CVE-2026-23475)
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:
nvdimm/bus: Fix potential use after free in asynchronous initialization
Dingisoul with KASAN reports a use after free if device_add() fails in
nd_async_device_register().
Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while
scheduling async init") correctly added a reference on the parent device
to be held until asynchronous initialization was complete. However, if
device_add() results in an allocation failure the ref count of the
device drops to 0 prior to the parent pointer being accessed. Thus
resulting in use after free.
The bug bot AI correctly identified the fix. Save a reference to the
parent pointer to be used to drop the parent reference regardless of the
outcome of device_add().(CVE-2026-31399)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix cache_request leak in cache_release
When a reader's file descriptor is closed while in the middle of reading
a cache_request (rp->offset != 0), cache_release() decrements the
request's readers count but never checks whether it should free the
request.
In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the
cache_request is removed from the queue and freed along with its buffer
and cache_head reference. cache_release() lacks this cleanup.
The only other path that frees requests with readers == 0 is
cache_dequeue(), but it runs only when CACHE_PENDING transitions from
set to clear. If that transition already happened while readers was
still non-zero, cache_dequeue() will have skipped the request, and no
subsequent call will clean it up.
Add the same cleanup logic from cache_read() to cache_release(): after
decrementing readers, check if it reached 0 with CACHE_PENDING clear,
and if so, dequeue and free the cache_request.(CVE-2026-31400)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd
The /proc/fs/nfs/exports proc entry is created at module init
and persists for the module's lifetime. exports_proc_open()
captures the caller's current network namespace and stores
its svc_export_cache in seq->private, but takes no reference
on the namespace. If the namespace is subsequently torn down
(e.g. container destruction after the opener does setns() to a
different namespace), nfsd_net_exit() calls nfsd_export_shutdown()
which frees the cache. Subsequent reads on the still-open fd
dereference the freed cache_detail, walking a freed hash table.
Hold a reference on the struct net for the lifetime of the open
file descriptor. This prevents nfsd_net_exit() from running --
and thus prevents nfsd_export_shutdown() from freeing the cache
-- while any exports fd is open. cache_detail already stores
its net pointer (cd->net, set by cache_create_net()), so
exports_release() can retrieve it without additional per-file
storage.(CVE-2026-31403)
In the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)
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:
ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()
When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware
platforms, it has already started the EC and installed the address
space handler with the struct acpi_ec pointer as handler context.
However, acpi_ec_setup() propagates the error without any cleanup.
The caller acpi_ec_add() then frees the struct acpi_ec for non-boot
instances, leaving a dangling handler context in ACPICA.
Any subsequent AML evaluation that accesses an EC OpRegion field
dispatches into acpi_ec_space_handler() with the freed pointer,
causing a use-after-free:
BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)
Write of size 8 at addr ffff88800721de38 by task init/1
Call Trace:
<TASK>
mutex_lock (kernel/locking/mutex.c:289)
acpi_ec_space_handler (drivers/acpi/ec.c:1362)
acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)
acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)
acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)
acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)
acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)
acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)
</TASK>
Allocated by task 1:
acpi_ec_alloc (drivers/acpi/ec.c:1424)
acpi_ec_add (drivers/acpi/ec.c:1692)
Freed by task 1:
kfree (mm/slub.c:6876)
acpi_ec_add (drivers/acpi/ec.c:1751)
The bug triggers on reduced-hardware EC platforms (ec->gpe < 0)
when the GPIO IRQ provider defers probing. Once the stale handler
exists, any unprivileged sysfs read that causes AML to touch an
EC OpRegion (battery, thermal, backlight) exercises the dangling
pointer.
Fix this by calling ec_remove_handlers() in the error path of
acpi_ec_setup() before clearing first_ec. ec_remove_handlers()
checks each EC_FLAGS_* bit before acting, so it is safe to call
regardless of how far ec_install_handlers() progressed:
-ENODEV (handler not installed): only calls acpi_ec_stop()
-EPROBE_DEFER (handler installed): removes handler, stops EC(CVE-2026-31426)
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:
ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops.
This results in the following warning splat:
WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) 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) _syssendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) _sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) 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:130) </TASK>
Fix this by allocating the size dynamically using nh_nlmsg_size() and using nlmsg_new(), this is consistent with nexthop_notify() behavior. In addition, adjust nh_nlmsg_size_grp() so it calculates the size needed based on flags passed. While at it, also add the size of NHA_FDB for nexthop group size calculation as it was missing too.
This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows:
addattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)
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:
bridge: br_nd_send: validate ND option lengths
br_nd_send() 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-31752)
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:
serial: 8250: Fix TX deadlock when using DMA
dmaengine_terminate_async does not guarantee that the
__dma_tx_complete callback will run. The callback is currently the
only place where dma->tx_running gets cleared. If the transaction is
canceled and the callback never runs, then dma->tx_running will never
get cleared and we will never schedule new TX DMA transactions again.
This change makes it so we clear dma->tx_running after we terminate
the DMA transaction. This is "safe" because serial8250_tx_dma_flush
is holding the UART port lock. The first thing the callback does is also
grab the UART port lock, so access to dma->tx_running is serialized.(CVE-2026-43061)
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:
ipv4: icmp: fix null-ptr-deref in icmp_build_probe()
ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref.
Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface".(CVE-2026-43099)
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:
net: usb: pegasus: enable basic endpoint checking
pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors:
- usb_rcvbulkpipe(dev, 1) for RX data
- usb_sndbulkpipe(dev, 2) for TX data
- usb_rcvintpipe(dev, 3) for status interrupts
A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes.
Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion.
Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")(CVE-2026-43156)
In the Linux kernel, the following vulnerability has been resolved:
md/bitmap: fix GPF in write_page caused by resize race
A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod]
This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over bitmap->storage.filemap
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). quiesce() does not stop the md thread,
allowing concurrent access to freed pages.
Fix by holding mddev->bitmap_info.mutex during the bitmap update.(CVE-2026-43163)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()
On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic.
Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it:
- in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation;
- in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written.
Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).(CVE-2026-43186)
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:
x86/kexec: add a sanity check on previous kernel's ima kexec buffer
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000
RIP: ima_restore_measurement_list+0xdc/0x45a
#PF: error_code(0x0000) – not-present page
Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Without carrying the measurement list across kexec, the attestation would fail.(CVE-2026-43240)
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:
ext4: move ext4_percpu_param_init() before ext4_mb_init()
When running kvm-xfstests -c ext4/1k -C 1 generic/383 with the
DOUBLE_CHECK macro defined, the following panic is triggered:
================================================================== EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================
This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test
With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above.
Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used.(CVE-2026-43288)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node
When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions.
The issue manifests in purge_vmap_node() -> kasan_release_vmalloc_node() where iterating through hundreds or thousands of vmap_area entries and freeing their associated shadow pages causes:
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299
Each call to kasan_release_vmalloc() can free many pages, and with page_owner tracking, each free triggers save_stack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section.
Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed
The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load.(CVE-2026-43292)
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:
io_uring/kbuf: check if target buffer list is still legacy on recycle
There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the buffer_list still exists, and if it's of the correct type. Add those checks.(CVE-2026-43366)
In the Linux kernel, the following vulnerability has been resolved:
libceph: prevent potential out-of-bounds reads in process_message_header()
If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header().
Perform an explicit bounds check before decoding the message header.(CVE-2026-43406)
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: class: cdc-wdm: fix reordering issue in read code path
Quoting the bug report:
Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1].
Fix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)
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:
net/mlx5: Fix deadlock between devlink lock and esw->wq
esw->work_queue executes esw_functions_changed_event_handler -> esw_vfs_changed_event_handler and acquires the devlink lock.
.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -> mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked -> mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlocks when esw_vfs_changed_event_handler executes.
Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5_eswitch_event_handler_unregister. - the counter is read and passed to the ephemeral mlx5_host_work struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5_eswitch_cleanup does the final draining before destroying the wq.
No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vport_change_handler work items, but that's ok since those are disabled elsewhere: - mlx5_eswitch_disable_locked disables the vport eq notifier. - mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything. - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.(CVE-2026-43468)
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)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()
Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().(CVE-2026-45834)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix slab-use-after-free in qd_put
Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list.
Fix this by removing qd objects from the LRU list before freeing them in qd_put().
Initial fix from Deepanshu Kartikey <(CVE-2026-45861)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix role switching during resume
If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.
The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.
So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---(CVE-2026-45911)
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix inline data read failure for ztailpacking pclusters
Compressed folios for ztailpacking pclusters must be valid before adding these pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster() may assume they are already valid and then trigger a NULL pointer dereference.
It is somewhat hard to reproduce because the inline data is in the same block as the tail of the compressed indexes, which are usually read just before. However, it may still happen if a fatal signal arrives while read_mapping_folio() is running, as shown below:
erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
...
pc : z_erofs_decompress_queue+0x4c8/0xa14 lr : z_erofs_decompress_queue+0x160/0xa14 sp : ffffffc08b3eb3a0 x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000 x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001 x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700 x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098 x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004 x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9 x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: z_erofs_decompress_queue+0x4c8/0xa14 z_erofs_runqueue+0x908/0x97c z_erofs_read_folio+0x128/0x228 filemap_read_folio+0x68/0x128 filemap_get_pages+0x44c/0x8b4 filemap_read+0x12c/0x5b8 generic_file_read_iter+0x4c/0x15c do_iter_readv_writev+0x188/0x1e0 vfs_iter_read+0xac/0x1a4 backing_file_read_iter+0x170/0x34c ovl_read_iter+0xf0/0x140 vfs_read+0x28c/0x344 ksys_read+0x80/0xf0 __arm64_sys_read+0x24/0x34 invoke_syscall+0x60/0x114 el0_svc_common+0x88/0xe4 do_el0_svc+0x24/0x30 el0_svc+0x40/0xa8 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1bc/0x1c0
Fix this by reading the inline data before allocating and adding the pclusters to the I/O chains.(CVE-2026-45943)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()
In amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM, the function returns directly without releasing the allocated xcc_info, resulting in a memory leak.
Fix this by ensuring that xcc_info is properly freed in the error paths.
Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-45947)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: fix memory leaks in gfs2_fill_super error path
Fix two memory leaks in the gfs2_fill_super() error handling path when transitioning a filesystem to read-write mode fails.
First leak: kthread objects (thread_struct, task_struct, etc.) When gfs2_freeze_lock_shared() fails after init_threads() succeeds, the created kernel threads (logd and quotad) are never destroyed. This occurs because the fail_per_node label doesn't call gfs2_destroy_threads().
Second leak: quota bitmap buffer (8192 bytes) When gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but before other operations complete, the allocated quota bitmap is never freed.
The fix moves thread cleanup to the fail_per_node label to handle all error paths uniformly. gfs2_destroy_threads() is safe to call unconditionally as it checks for NULL pointers. Quota cleanup is added in gfs2_make_fs_rw() to properly handle the withdrawal case where quota initialization succeeds but the filesystem is then withdrawn.
Thread leak backtrace (gfs2_freeze_lock_shared failure): unreferenced object 0xffff88801d7bca80 (size 4480): copy_process+0x3a1/0x4670 kernel/fork.c:2422 kernel_clone+0xf3/0x6e0 kernel/fork.c:2779 kthread_create_on_node+0x100/0x150 kernel/kthread.c:478 init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611 gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265
Quota leak backtrace (gfs2_make_fs_rw failure): unreferenced object 0xffff88812de7c000 (size 8192): gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409 gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149 gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()
Cover a missed execution path with a new check.(CVE-2026-45982)
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()
Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array.
However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path.
Let's add an additional check to fix this for backporting.
Reproducible image (base64-encoded gzipped blob):
H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA=
$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)
In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running. The Linux kernel CVE team has assigned CVE-2026-46044 to this issue.(CVE-2026-46044)
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe(). The Linux kernel CVE team has assigned CVE-2026-46051 to this issue.(CVE-2026-46051)
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs] The Linux kernel CVE team has assigned CVE-2026-46076 to this issue.(CVE-2026-46076)
In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of sizeof(struct erofs_dirent) as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com The Linux kernel CVE team has assigned CVE-2026-46078 to this issue.(CVE-2026-46078)
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@] The Linux kernel CVE team has assigned CVE-2026-46082 to this issue.(CVE-2026-46082)
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: take vmap_purge_lock in shrinker decay_va_pool_node() can be invoked concurrently from two paths: __purge_vmap_area_lazy() when pools are being purged, and the shrinker via vmap_node_shrink_scan(). However, decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks. Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker path to ensure serialization with purge users. The Linux kernel CVE team has assigned CVE-2026-46093 to this issue.(CVE-2026-46093)
In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lockPatch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path".Reads of 'memcg_path' and 'path' files in DAMON sysfs interface could racewith their writes, results in use-after-free. Fix those.This patch (of 2):damon_sysfs_scheme_filter->mmecg_path can be read and written by users,via DAMON sysfs memcg_path file. It can also be indirectly read, for theparameters {on,off}line committing to DAMON. The reads for parameterscommitting are protected by damon_sysfs_lock to avoid the sysfs filesbeing destroyed while any of the parameters are being read. But theuser-driven direct reads and writes are not protected by any lock, whilethe write is deallocating the memcg_path-pointing buffer. As a result,the readers could read the already freed buffer (user-after-free). Notethat the user-reads don't race when the same open file is used by thewriter, due to kernfs's open file locking. Nonetheless, doing the readsand writes with separate open files would be common. Fix it by protectingboth the user-direct reads and writes with damon_sysfs_lock.(CVE-2026-46121)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt
hci_le_create_big_complete_evt() iterates over BT_BOUND connections for a BIG handle using a while loop, accessing ev->bis_handle[i++] on each iteration. However, there is no check that i stays within ev->num_bis before the array access.
When a controller sends a LE_Create_BIG_Complete event with fewer bis_handle entries than there are BT_BOUND connections for that BIG, or with num_bis=0, the loop reads beyond the valid bis_handle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle() rejects them and the connection remains in BT_BOUND state. The same connection is then found again by hci_conn_hash_lookup_big_state(), creating an infinite loop with hci_dev_lock held.
Fix this by terminating the BIG if in case not all BIS could be setup properly.(CVE-2026-46138)
In the Linux kernel, vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. The rtnl_delete_link() must happen under RTNL and cannot be executed in RCU context. Calling synchronize_net() while holding RTNL is not good for performance and system stability, so calling netdev_put() in RCU call is the right solution. However, when the device is deleted, rtnl_unlock() calls netdev_run_todo() and blocks until all references are gone. In the current code, this means that call_rcu() is never reached, the vport is never freed, and the reference is never released, causing a self-deadlock on device removal. The fix moves the rcu_call() before rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from rtnl_unlock()->netdev_run_todo() while RTNL itself is already released.(CVE-2026-46165)
In the Linux kernel's RISC-V KVM subsystem, when the second kzalloc (host_context.vector.datap) fails in kvm_riscv_vcpu_alloc_vector_context, the first allocation (guest_context.vector.datap) is not freed, causing a memory leak. An attacker can trigger this via ioctl(vm_fd, KVM_CREATE_VCPU), potentially leading to resource exhaustion.(CVE-2026-46171)
In the Linux kernel, the mlx4_ib_create_srq() function fails to release resources allocated by mlx4_srq_alloc() in error handling paths, leading to a resource leak. An attacker could exploit this vulnerability to cause resource exhaustion or denial of service.(CVE-2026-46178)
In the Linux kernel, the spi_nor_params_show() function uses sizeof(snor_f_names) to calculate the array length. Since snor_f_names is an array of pointers, sizeof returns the total byte size of the pointer array (element_count sizeof(void )), which on 64-bit systems is 8 times larger than intended. This causes an out-of-bounds read when a flag bit is set that exceeds the actual element count but falls within the inflated byte-size count. The fix replaces sizeof with ARRAY_SIZE to pass the actual number of elements.(CVE-2026-46190)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-debugsource-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-devel-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-headers-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-source-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-tools-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"perf-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"perf-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"python3-perf-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.3.14.145.oe2403sp3.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-debugsource-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-devel-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-headers-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-source-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-tools-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"perf-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"perf-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"python3-perf-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.3.14.145.oe2403sp3"
}
],
"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\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\nmlxsw: spectrum_router: Fix neighbour use-after-free\n\nWe sometimes observe use-after-free when dereferencing a neighbour [1].\nThe problem seems to be that the driver stores a pointer to the\nneighbour, but without holding a reference on it. A reference is only\ntaken when the neighbour is used by a nexthop.\n\nFix by simplifying the reference counting scheme. Always take a\nreference when storing a neighbour pointer in a neighbour entry. Avoid\ntaking a referencing when the neighbour is used by a nexthop as the\nneighbour entry associated with the nexthop already holds a reference.\n\nTested by running the test that uncovered the problem over 300 times.\nWithout this patch the problem was reproduced after a handful of\niterations.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310\nRead of size 8 at addr ffff88817f8e3420 by task ip/3929\n\nCPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6e/0x300\n print_report+0xfc/0x1fb\n kasan_report+0xe4/0x110\n mlxsw_sp_neigh_entry_update+0x2d4/0x310\n mlxsw_sp_router_rif_gone_sync+0x35f/0x510\n mlxsw_sp_rif_destroy+0x1ea/0x730\n mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0\n __mlxsw_sp_inetaddr_lag_event+0xcc/0x130\n __mlxsw_sp_inetaddr_event+0xf5/0x3c0\n mlxsw_sp_router_netdevice_event+0x1015/0x1580\n notifier_call_chain+0xcc/0x150\n call_netdevice_notifiers_info+0x7e/0x100\n __netdev_upper_dev_unlink+0x10b/0x210\n netdev_upper_dev_unlink+0x79/0xa0\n vrf_del_slave+0x18/0x50\n do_set_master+0x146/0x7d0\n do_setlink.isra.0+0x9a0/0x2880\n rtnl_newlink+0x637/0xb20\n rtnetlink_rcv_msg+0x6fe/0xb90\n netlink_rcv_skb+0x123/0x380\n netlink_unicast+0x4a3/0x770\n netlink_sendmsg+0x75b/0xc90\n __sock_sendmsg+0xbe/0x160\n ____sys_sendmsg+0x5b2/0x7d0\n ___sys_sendmsg+0xfd/0x180\n __sys_sendmsg+0x124/0x1c0\n do_syscall_64+0xbb/0xfd0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[...]\n\nAllocated by task 109:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x2c1/0x790\n neigh_alloc+0x6af/0x8f0\n ___neigh_create+0x63/0xe90\n mlxsw_sp_nexthop_neigh_init+0x430/0x7e0\n mlxsw_sp_nexthop_type_init+0x212/0x960\n mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280\n mlxsw_sp_nexthop6_group_get+0x392/0x6a0\n mlxsw_sp_fib6_entry_create+0x46a/0xfd0\n mlxsw_sp_router_fib6_replace+0x1ed/0x5f0\n mlxsw_sp_router_fib6_event_work+0x10a/0x2a0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nFreed by task 154:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x43/0x70\n kmem_cache_free_bulk.part.0+0x1eb/0x5e0\n kvfree_rcu_bulk+0x1f2/0x260\n kfree_rcu_work+0x130/0x1b0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nLast potentially related work creation:\n kasan_save_stack+0x30/0x50\n kasan_record_aux_stack+0x8c/0xa0\n kvfree_call_rcu+0x93/0x5b0\n mlxsw_sp_router_neigh_event_work+0x67d/0x860\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20(CVE-2025-68801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: bound check rq_pages index in inline path\n\nsvc_rdma_copy_inline_range indexed rqstp-\u0026gt;rq_pages[rc_curpage] without\nverifying rc_curpage stays within the allocated page array. Add guards\nbefore the first use and after advancing to a new page.(CVE-2025-71068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\u0026quot;i40evf: Allow PF driver to configure RSS\u0026quot;),\nthe loop upper bounds were:\n i \u0026lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u0026lt;= adapter-\u0026gt;rss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u0026lt;=`\naccesses one element past the end.\n\nFix the issues by using `\u0026lt;` instead of `\u0026lt;=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u0026gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)\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\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn\u0026apos;t make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n the elevated refcount on the conduit\u0026apos;s kobject. Nominally, the OF and\n non-OF paths should result in objects having identical reference\n counts taken, and it is already suspicious that\n dsa_dev_to_net_device() has a put_device() call which is missing in\n dsa_port_parse_of(), but we can actually even verify that an issue\n exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n \u0026quot;before\u0026quot; and \u0026quot;after\u0026quot; applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 \u0026gt; /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: \u0026apos;eno2\u0026apos; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: \u0026apos;109\u0026apos; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n it can get unregistered at any time, and DSA remains with a long-lived,\n but in this case stale, cpu_dp-\u0026gt;conduit pointer. Holding the net\n device\u0026apos;s underlying kobject isn\u0026apos;t actually of much help, it just\n prevents it from being freed (but we never need that kobject\n directly). What helps us to prevent the net device from being\n unregistered is the parallel netdev reference mechanism (dev_hold()\n and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\u0026quot;net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\u0026quot;), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn\u0026apos;t know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n ports failed to probe, see commit 86f8b1c01a0a (\u0026quot;net: dsa: Do not\n make user port errors fatal\u0026quot;), and the cpu_dp-\u0026gt;conduit pointers\n remain valid. I haven\u0026apos;t audited all call paths to see whether they\n will actually use the conduit in lack of any user port, but if they\n do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n associated to, and we can get into a situation where we\u0026apos;ve moved all\n user ports away from a conduit, thus no longer hold any reference to\n it via the net device tracker. But we shouldn\u0026apos;t let it go nonetheless\n - see the next change in relation to dsa_tree_find_first_conduit()\n and LAG conduits which disappear.\n We have to be prepared to return to the physical conduit, so the CPU\n port must explicitly keep another reference to it. This is also to\n say: the user ports and their CPU ports may not always keep a\n reference to the same conduit net device, and both are needed.\n\nAs for the conduit\u0026apos;s kobject for the /sys/class/net/ entry, we don\u0026apos;t\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I\u0026apos;ll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---(CVE-2025-71152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\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\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\nipv4: ip_gre: make ipgre_header() robust\n\nAnalog to commit db5b4e39c4e6 (\u0026quot;ip6_gre: make ip6gre_header() robust\u0026quot;)\n\nOver the years, syzbot found many ways to crash the kernel\nin ipgre_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 ipgre device.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0\n kernel BUG at net/core/skbuff.c:213 !\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nWorkqueue: mld mld_ifc_work\n RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213\nCall Trace:\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 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897\n dev_hard_header include/linux/netdevice.h:3436 [inline]\n neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618\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\n process_one_work kernel/workqueue.c:3257 [inline]\n process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n kthread+0x711/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246(CVE-2026-23011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: prevent pcp corruption with SMP=n\n\nThe kernel test robot has reported:\n\n BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28\n lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0\n CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack (lib/dump_stack.c:95)\n dump_stack_lvl (lib/dump_stack.c:123)\n dump_stack (lib/dump_stack.c:130)\n spin_dump (kernel/locking/spinlock_debug.c:71)\n do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?)\n _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138)\n __free_frozen_pages (mm/page_alloc.c:2973)\n ___free_pages (mm/page_alloc.c:5295)\n __free_pages (mm/page_alloc.c:5334)\n tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290)\n ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289)\n ? rcu_core (kernel/rcu/tree.c:?)\n rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861)\n rcu_core_si (kernel/rcu/tree.c:2879)\n handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623)\n __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725)\n irq_exit_rcu (kernel/softirq.c:741)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052)\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194)\n free_pcppages_bulk (mm/page_alloc.c:1494)\n drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632)\n __drain_all_pages (mm/page_alloc.c:2731)\n drain_all_pages (mm/page_alloc.c:2747)\n kcompactd (mm/compaction.c:3115)\n kthread (kernel/kthread.c:465)\n ? __cfi_kcompactd (mm/compaction.c:3166)\n ? __cfi_kthread (kernel/kthread.c:412)\n ret_from_fork (arch/x86/kernel/process.c:164)\n ? __cfi_kthread (kernel/kthread.c:412)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:255)\n \u0026lt;/TASK\u0026gt;\n\nMatthew has analyzed the report and identified that in drain_page_zone()\nwe are in a section protected by spin_lock(\u0026amp;pcp-\u0026gt;lock) and then get an\ninterrupt that attempts spin_trylock() on the same lock. The code is\ndesigned to work this way without disabling IRQs and occasionally fail the\ntrylock with a fallback. However, the SMP=n spinlock implementation\nassumes spin_trylock() will always succeed, and thus it\u0026apos;s normally a\nno-op. Here the enabled lock debugging catches the problem, but otherwise\nit could cause a corruption of the pcp structure.\n\nThe problem has been introduced by commit 574907741599 (\u0026quot;mm/page_alloc:\nleave IRQs enabled for per-cpu page allocations\u0026quot;). The pcp locking scheme\nrecognizes the need for disabling IRQs to prevent nesting spin_trylock()\nsections on SMP=n, but the need to prevent the nesting in spin_lock() has\nnot been recognized. Fix it by introducing local wrappers that change the\nspin_lock() to spin_lock_iqsave() with SMP=n and use them in all places\nthat do spin_lock(\u0026amp;pcp-\u0026gt;lock).\n\n[(CVE-2026-23025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hv_netvsc: reject RSS hash key programming without RX indirection table\n\nRSS configuration requires a valid RX indirection table. When the device\nreports a single receive queue, rndis_filter_device_add() does not\nallocate an indirection table, accepting RSS hash key updates in this\nstate leads to a hang.\n\nFix this by gating netvsc_set_rxfh() on ndc-\u0026gt;rx_table_sz and return\n-EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device\ncapabilities and prevents incorrect behavior.(CVE-2026-23054)\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\nmm/hugetlb: fix hugetlb_pmd_shared()\n\nPatch series \u0026quot;mm/hugetlb: fixes for PMD table sharing (incl. using\nmmu_gather)\u0026quot;, v3.\n\nOne functional fix, one performance regression fix, and two related\ncomment fixes.\n\nI cleaned up my prototype I recently shared [1] for the performance fix,\ndeferring most of the cleanups I had in the prototype to a later point. \nWhile doing that I identified the other things.\n\nThe goal of this patch set is to be backported to stable trees \u0026quot;fairly\u0026quot;\neasily. At least patch #1 and #4.\n\nPatch #1 fixes hugetlb_pmd_shared() not detecting any sharing\nPatch #2 + #3 are simple comment fixes that patch #4 interacts with.\nPatch #4 is a fix for the reported performance regression due to excessive\nIPI broadcasts during fork()+exit().\n\nThe last patch is all about TLB flushes, IPIs and mmu_gather.\nRead: complicated\n\nThere are plenty of cleanups in the future to be had + one reasonable\noptimization on x86. But that\u0026apos;s all out of scope for this series.\n\nRuntime tested, with a focus on fixing the performance regression using\nthe original reproducer [2] on x86.\n\n\nThis patch (of 4):\n\nWe switched from (wrongly) using the page count to an independent shared\ncount. Now, shared page tables have a refcount of 1 (excluding\nspeculative references) and instead use ptdesc-\u0026gt;pt_share_count to identify\nsharing.\n\nWe didn\u0026apos;t convert hugetlb_pmd_shared(), so right now, we would never\ndetect a shared PMD table as such, because sharing/unsharing no longer\ntouches the refcount of a PMD table.\n\nPage migration, like mbind() or migrate_pages() would allow for migrating\nfolios mapped into such shared PMD tables, even though the folios are not\nexclusive. In smaps we would account them as \u0026quot;private\u0026quot; although they are\n\u0026quot;shared\u0026quot;, and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the\npagemap interface.\n\nFix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().(CVE-2026-23100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add recursion protection in kernel stack trace recording\n\nA bug was reported about an infinite recursion caused by tracing the rcu\nevents with the kernel stack trace trigger enabled. The stack trace code\ncalled back into RCU which then called the stack trace again.\n\nExpand the ftrace recursion protection to add a set of bits to protect\nevents from recursion. Each bit represents the context that the event is\nin (normal, softirq, interrupt and NMI).\n\nHave the stack trace code use the interrupt context to protect against\nrecursion.\n\nNote, the bug showed an issue in both the RCU code as well as the tracing\nstacktrace code. This only handles the tracing stack trace side of the\nbug. The RCU fix will be handled separately.(CVE-2026-23138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: secure_seq: add back ports to TS offset\n\nThis reverts 28ee1b746f49 (\u0026quot;secure_seq: downgrade to per-host timestamp offsets\u0026quot;)\n\ntcp_tw_recycle went away in 2017.\n\nZhouyan Deng reported off-path TCP source port leakage via\nSYN cookie side-channel that can be fixed in multiple ways.\n\nOne of them is to bring back TCP ports in TS offset randomization.\n\nAs a bonus, we perform a single siphash() computation\nto provide both an ISN and a TS offset.(CVE-2026-23247)\n\nIn the Linux kernel, a vulnerability exists in the AppArmor module\u0026apos;s unpack_pdb function. The vulnerability occurs due to failure to validate that DFA start states are within bounds, which can lead to out-of-bound reads. An attacker can exploit this vulnerability through specially crafted policy files, potentially leading to information disclosure or system crashes.(CVE-2026-23269)\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/sched: act_ife: Fix metalist update behavior\n\nWhenever an ife action replace changes the metalist, instead of\nreplacing the old data on the metalist, the current ife code is appending\nthe new metadata. Aside from being innapropriate behavior, this may lead\nto an unbounded addition of metadata to the metalist which might cause an\nout of bounds error when running the encode op:\n\n[ 138.423369][ C1] ==================================================================\n[ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255\n[ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)\n[ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[ 138.425800][ C1] Call Trace:\n[ 138.425804][ C1] \u0026lt;IRQ\u0026gt;\n[ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122)\n[ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))\n[ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597)\n[ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1))\n[ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2))\n[ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171)\n[ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57)\n[ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114)\n[ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3))\n[ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45)\n[ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)\n\nTo solve this issue, fix the replace behavior by adding the metalist to\nthe ife rcu data structure.(CVE-2026-23378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix memory leak in ice_set_ringparam()\n\nIn ice_set_ringparam, tx_rings and xdp_rings are allocated before\nrx_rings. If the allocation of rx_rings fails, the code jumps to\nthe done label leaking both tx_rings and xdp_rings. Furthermore, if\nthe setup of an individual Rx ring fails during the loop, the code jumps\nto the free_tx label which releases tx_rings but leaks xdp_rings.\n\nFix this by introducing a free_xdp label and updating the error paths to\nensure both xdp_rings and tx_rings are properly freed if rx_rings\nallocation or setup fails.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-23389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix side-effect bug in match_char() macro usage\n\nThe match_char() macro evaluates its character parameter multiple\ntimes when traversing differential encoding chains. When invoked\nwith *str++, the string pointer advances on each iteration of the\ninner do-while loop, causing the DFA to check different characters\nat each iteration and therefore skip input characters.\nThis results in out-of-bounds reads when the pointer advances past\nthe input buffer boundary.\n\n[ 94.984676] ==================================================================\n[ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760\n[ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976\n\n[ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)\n[ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 94.986329] Call Trace:\n[ 94.986341] \u0026lt;TASK\u0026gt;\n[ 94.986347] dump_stack_lvl+0x5e/0x80\n[ 94.986374] print_report+0xc8/0x270\n[ 94.986384] ? aa_dfa_match+0x5ae/0x760\n[ 94.986388] kasan_report+0x118/0x150\n[ 94.986401] ? aa_dfa_match+0x5ae/0x760\n[ 94.986405] aa_dfa_match+0x5ae/0x760\n[ 94.986408] __aa_path_perm+0x131/0x400\n[ 94.986418] aa_path_perm+0x219/0x2f0\n[ 94.986424] apparmor_file_open+0x345/0x570\n[ 94.986431] security_file_open+0x5c/0x140\n[ 94.986442] do_dentry_open+0x2f6/0x1120\n[ 94.986450] vfs_open+0x38/0x2b0\n[ 94.986453] ? may_open+0x1e2/0x2b0\n[ 94.986466] path_openat+0x231b/0x2b30\n[ 94.986469] ? __x64_sys_openat+0xf8/0x130\n[ 94.986477] do_file_open+0x19d/0x360\n[ 94.986487] do_sys_openat2+0x98/0x100\n[ 94.986491] __x64_sys_openat+0xf8/0x130\n[ 94.986499] do_syscall_64+0x8e/0x660\n[ 94.986515] ? count_memcg_events+0x15f/0x3c0\n[ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986540] ? handle_mm_fault+0x1639/0x1ef0\n[ 94.986551] ? vma_start_read+0xf0/0x320\n[ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0\n[ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0\n[ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986588] ? irqentry_exit+0x3c/0x590\n[ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 94.986597] RIP: 0033:0x7fda4a79c3ea\n\nFix by extracting the character value before invoking match_char,\nensuring single evaluation per outer loop.(CVE-2026-23406)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix missing bounds check on DEFAULT table in verify_dfa()\n\nThe verify_dfa() function only checks DEFAULT_TABLE bounds when the state\nis not differentially encoded.\n\nWhen the verification loop traverses the differential encoding chain,\nit reads k = DEFAULT_TABLE[j] and uses k as an array index without\nvalidation. A malformed DFA with DEFAULT_TABLE[j] \u0026gt;= state_count,\ntherefore, causes both out-of-bounds reads and writes.\n\n[ 57.179855] ==================================================================\n[ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660\n[ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993\n\n[ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)\n[ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 57.181563] Call Trace:\n[ 57.181572] \u0026lt;TASK\u0026gt;\n[ 57.181577] dump_stack_lvl+0x5e/0x80\n[ 57.181596] print_report+0xc8/0x270\n[ 57.181605] ? verify_dfa+0x59a/0x660\n[ 57.181608] kasan_report+0x118/0x150\n[ 57.181620] ? verify_dfa+0x59a/0x660\n[ 57.181623] verify_dfa+0x59a/0x660\n[ 57.181627] aa_dfa_unpack+0x1610/0x1740\n[ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470\n[ 57.181640] unpack_pdb+0x86d/0x46b0\n[ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181656] ? aa_unpack_nameX+0x1a8/0x300\n[ 57.181659] aa_unpack+0x20b0/0x4c30\n[ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181664] ? stack_depot_save_flags+0x33/0x700\n[ 57.181681] ? kasan_save_track+0x4f/0x80\n[ 57.181683] ? kasan_save_track+0x3e/0x80\n[ 57.181686] ? __kasan_kmalloc+0x93/0xb0\n[ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780\n[ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130\n[ 57.181697] ? policy_update+0x154/0x330\n[ 57.181704] aa_replace_profiles+0x15a/0x1dd0\n[ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780\n[ 57.181712] ? aa_loaddata_alloc+0x77/0x140\n[ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181717] ? _copy_from_user+0x2a/0x70\n[ 57.181730] policy_update+0x17a/0x330\n[ 57.181733] profile_replace+0x153/0x1a0\n[ 57.181735] ? rw_verify_area+0x93/0x2d0\n[ 57.181740] vfs_write+0x235/0xab0\n[ 57.181745] ksys_write+0xb0/0x170\n[ 57.181748] do_syscall_64+0x8e/0x660\n[ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 57.181765] RIP: 0033:0x7f6192792eb2\n\nRemove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE\nentries unconditionally.(CVE-2026-23407)\n\nA race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)\n\nA vulnerability exists in the AppArmor security module of the Linux kernel when handling the i_private field of the inode structure. AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor\u0026apos;s access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n\n\nWhen CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0\n(success) without actually creating a socket. Callers such as\nfou_create() then proceed to dereference the uninitialized socket\npointer, resulting in a NULL pointer dereference.\n\nThe captured NULL deref crash:\n BUG: kernel NULL pointer dereference, address: 0000000000000018\n RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764)\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114)\n genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209)\n [...]\n netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n genl_rcv (net/netlink/genetlink.c:1219)\n netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n netlink_sendmsg (net/netlink/af_netlink.c:1894)\n __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1))\n __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1))\n __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1))\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)\n\nThis patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so\ncallers correctly take their error paths. There is only one caller of\nthe vulnerable function and only privileged users can trigger it.(CVE-2026-23439)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race condition during IPSec ESN update\n\nIn IPSec full offload mode, the device reports an ESN (Extended\nSequence Number) wrap event to the driver. The driver validates this\nevent by querying the IPSec ASO and checking that the esn_event_arm\nfield is 0x0, which indicates an event has occurred. After handling\nthe event, the driver must re-arm the context by setting esn_event_arm\nback to 0x1.\n\nA race condition exists in this handling path. After validating the\nevent, the driver calls mlx5_accel_esp_modify_xfrm() to update the\nkernel\u0026apos;s xfrm state. This function temporarily releases and\nre-acquires the xfrm state lock.\n\nSo, need to acknowledge the event first by setting esn_event_arm to\n0x1. This prevents the driver from reprocessing the same ESN update if\nthe hardware sends events for other reason. Since the next ESN update\nonly occurs after nearly 2^31 packets are received, there\u0026apos;s no risk of\nmissing an update, as it will happen long after this handling has\nfinished.\n\nProcessing the event twice causes the ESN high-order bits (esn_msb) to\nbe incremented incorrectly. The driver then programs the hardware with\nthis invalid ESN state, which leads to anti-replay failures and a\ncomplete halt of IPSec traffic.\n\nFix this by re-arming the ESN event immediately after it is validated,\nbefore calling mlx5_accel_esp_modify_xfrm(). This ensures that any\nspurious, duplicate events are correctly ignored, closing the race\nwindow.(CVE-2026-23440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Prevent concurrent access to IPSec ASO context\n\nThe query or updating IPSec offload object is through Access ASO WQE.\nThe driver uses a single mlx5e_ipsec_aso struct for each PF, which\ncontains a shared DMA-mapped context for all ASO operations.\n\nA race condition exists because the ASO spinlock is released before\nthe hardware has finished processing WQE. If a second operation is\ninitiated immediately after, it overwrites the shared context in the\nDMA area.\n\nWhen the first operation\u0026apos;s completion is processed later, it reads\nthis corrupted context, leading to unexpected behavior and incorrect\nresults.\n\nThis commit fixes the race by introducing a private context within\neach IPSec offload object. The shared ASO context is now copied to\nthis private context while the ASO spinlock is held. Subsequent\nprocessing uses this saved, per-object context, ensuring its integrity\nis maintained.(CVE-2026-23441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure\n\nieee80211_tx_prepare_skb() has three error paths, but only two of them\nfree the skb. The first error path (ieee80211_tx_prepare() returning\nTX_DROP) does not free it, while invoke_tx_handlers() failure and the\nfragmentation check both do.\n\nAdd kfree_skb() to the first error path so all three are consistent,\nand remove the now-redundant frees in callers (ath9k, mt76,\nmac80211_hwsim) to avoid double-free.\n\nDocument the skb ownership guarantee in the function\u0026apos;s kdoc.(CVE-2026-23444)\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\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()\n\nSyzkaller reported a panic in smc_tcp_syn_recv_sock() [1].\n\nsmc_tcp_syn_recv_sock() is called in the TCP receive path\n(softirq) via icsk_af_ops-\u0026gt;syn_recv_sock on the clcsock (TCP\nlistening socket). It reads sk_user_data to get the smc_sock\npointer. However, when the SMC listen socket is being closed\nconcurrently, smc_close_active() sets clcsock-\u0026gt;sk_user_data\nto NULL under sk_callback_lock, and then the smc_sock itself\ncan be freed via sock_put() in smc_release().\n\nThis leads to two issues:\n\n1) NULL pointer dereference: sk_user_data is NULL when\n accessed.\n2) Use-after-free: sk_user_data is read as non-NULL, but the\n smc_sock is freed before its fields (e.g., queued_smc_hs,\n ori_af_ops) are accessed.\n\nThe race window looks like this (the syzkaller crash [1]\ntriggers via the SYN cookie path: tcp_get_cookie_sock() -\u0026gt;\nsmc_tcp_syn_recv_sock(), but the normal tcp_check_req() path\nhas the same race):\n\n CPU A (softirq) CPU B (process ctx)\n\n tcp_v4_rcv()\n TCP_NEW_SYN_RECV:\n sk = req-\u0026gt;rsk_listener\n sock_hold(sk)\n /* No lock on listener */\n smc_close_active():\n write_lock_bh(cb_lock)\n sk_user_data = NULL\n write_unlock_bh(cb_lock)\n ...\n smc_clcsock_release()\n sock_put(smc-\u0026gt;sk) x2\n -\u0026gt; smc_sock freed!\n tcp_check_req()\n smc_tcp_syn_recv_sock():\n smc = user_data(sk)\n -\u0026gt; NULL or dangling\n smc-\u0026gt;queued_smc_hs\n -\u0026gt; crash!\n\nNote that the clcsock and smc_sock are two independent objects\nwith separate refcounts. TCP stack holds a reference on the\nclcsock, which keeps it alive, but this does NOT prevent the\nsmc_sock from being freed.\n\nFix this by using RCU and refcount_inc_not_zero() to safely\naccess smc_sock. Since smc_tcp_syn_recv_sock() is called in\nthe TCP three-way handshake path, taking read_lock_bh on\nsk_callback_lock is too heavy and would not survive a SYN\nflood attack. Using rcu_read_lock() is much more lightweight.\n\n- Set SOCK_RCU_FREE on the SMC listen socket so that\n smc_sock freeing is deferred until after the RCU grace\n period. This guarantees the memory is still valid when\n accessed inside rcu_read_lock().\n- Use rcu_read_lock() to protect reading sk_user_data.\n- Use refcount_inc_not_zero(\u0026amp;smc-\u0026gt;sk.sk_refcnt) to pin the\n smc_sock. If the refcount has already reached zero (close\n path completed), it returns false and we bail out safely.\n\nNote: smc_hs_congested() has a similar lockless read of\nsk_user_data without rcu_read_lock(), but it only checks for\nNULL and accesses the global smc_hs_wq, never dereferencing\nany smc_sock field, so it is not affected.\n\nReproducer was verified with mdelay injection and smc_run,\nthe issue no longer occurs with this patch applied.\n\n[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9(CVE-2026-23450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM: runtime: Fix a race condition related to device removal\n\nThe following code in pm_runtime_work() may dereference the dev-\u0026gt;parent\npointer after the parent device has been freed:\n\n\t/* Maybe the parent is now able to suspend. */\n\tif (parent \u0026amp;\u0026amp; !parent-\u0026gt;power.ignore_children) {\n\t\tspin_unlock(\u0026amp;dev-\u0026gt;power.lock);\n\n\t\tspin_lock(\u0026amp;parent-\u0026gt;power.lock);\n\t\trpm_idle(parent, RPM_ASYNC);\n\t\tspin_unlock(\u0026amp;parent-\u0026gt;power.lock);\n\n\t\tspin_lock(\u0026amp;dev-\u0026gt;power.lock);\n\t}\n\nFix this by inserting a flush_work() call in pm_runtime_remove().\n\nWithout this patch blktest block/001 triggers the following complaint\nsporadically:\n\nBUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160\nRead of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081\nWorkqueue: pm pm_runtime_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x61/0x80\n print_address_description.constprop.0+0x8b/0x310\n print_report+0xfd/0x1d7\n kasan_report+0xd8/0x1d0\n __kasan_check_byte+0x42/0x60\n lock_acquire.part.0+0x38/0x230\n lock_acquire+0x70/0x160\n _raw_spin_lock+0x36/0x50\n rpm_suspend+0xc6a/0xfe0\n rpm_idle+0x578/0x770\n pm_runtime_work+0xee/0x120\n process_one_work+0xde3/0x1410\n worker_thread+0x5eb/0xfe0\n kthread+0x37b/0x480\n ret_from_fork+0x6cb/0x920\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_alloc_info+0x3d/0x50\n __kasan_kmalloc+0xa0/0xb0\n __kmalloc_noprof+0x311/0x990\n scsi_alloc_target+0x122/0xb60 [scsi_mod]\n __scsi_scan_target+0x101/0x460 [scsi_mod]\n scsi_scan_channel+0x179/0x1c0 [scsi_mod]\n scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]\n store_scan+0x2d2/0x390 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810\n do_syscall_64+0xee/0xfc0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFreed by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_free_info+0x3f/0x50\n __kasan_slab_free+0x67/0x80\n kfree+0x225/0x6c0\n scsi_target_dev_release+0x3d/0x60 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_put+0x7f/0xc0 [scsi_mod]\n sdev_store_delete+0xa5/0x120 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810(CVE-2026-23452)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user\n\nAfter commit ab4eedb790ca (\u0026quot;Bluetooth: L2CAP: Fix corrupted list in\nhci_chan_del\u0026quot;), l2cap_conn_del() uses conn-\u0026gt;lock to protect access to\nconn-\u0026gt;users. However, l2cap_register_user() and l2cap_unregister_user()\ndon\u0026apos;t use conn-\u0026gt;lock, creating a race condition where these functions can\naccess conn-\u0026gt;users and conn-\u0026gt;hchan concurrently with l2cap_conn_del().\n\nThis can lead to use-after-free and list corruption bugs, as reported\nby syzbot.\n\nFix this by changing l2cap_register_user() and l2cap_unregister_user()\nto use conn-\u0026gt;lock instead of hci_dev_lock(), ensuring consistent locking\nfor the l2cap_conn structure.(CVE-2026-23461)\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\nspi: fix statistics allocation\n\nThe controller per-cpu statistics is not allocated until after the\ncontroller has been registered with driver core, which leaves a window\nwhere accessing the sysfs attributes can trigger a NULL-pointer\ndereference.\n\nFix this by moving the statistics allocation to controller allocation\nwhile tying its lifetime to that of the controller (rather than using\nimplicit devres).(CVE-2026-23475)\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\nnvdimm/bus: Fix potential use after free in asynchronous initialization\n\nDingisoul with KASAN reports a use after free if device_add() fails in\nnd_async_device_register().\n\nCommit b6eae0f61db2 (\u0026quot;libnvdimm: Hold reference on parent while\nscheduling async init\u0026quot;) correctly added a reference on the parent device\nto be held until asynchronous initialization was complete. However, if\ndevice_add() results in an allocation failure the ref count of the\ndevice drops to 0 prior to the parent pointer being accessed. Thus\nresulting in use after free.\n\nThe bug bot AI correctly identified the fix. Save a reference to the\nparent pointer to be used to drop the parent reference regardless of the\noutcome of device_add().(CVE-2026-31399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix cache_request leak in cache_release\n\nWhen a reader\u0026apos;s file descriptor is closed while in the middle of reading\na cache_request (rp-\u0026gt;offset != 0), cache_release() decrements the\nrequest\u0026apos;s readers count but never checks whether it should free the\nrequest.\n\nIn cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the\ncache_request is removed from the queue and freed along with its buffer\nand cache_head reference. cache_release() lacks this cleanup.\n\nThe only other path that frees requests with readers == 0 is\ncache_dequeue(), but it runs only when CACHE_PENDING transitions from\nset to clear. If that transition already happened while readers was\nstill non-zero, cache_dequeue() will have skipped the request, and no\nsubsequent call will clean it up.\n\nAdd the same cleanup logic from cache_read() to cache_release(): after\ndecrementing readers, check if it reached 0 with CACHE_PENDING clear,\nand if so, dequeue and free the cache_request.(CVE-2026-31400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd\n\nThe /proc/fs/nfs/exports proc entry is created at module init\nand persists for the module\u0026apos;s lifetime. exports_proc_open()\ncaptures the caller\u0026apos;s current network namespace and stores\nits svc_export_cache in seq-\u0026gt;private, but takes no reference\non the namespace. If the namespace is subsequently torn down\n(e.g. container destruction after the opener does setns() to a\ndifferent namespace), nfsd_net_exit() calls nfsd_export_shutdown()\nwhich frees the cache. Subsequent reads on the still-open fd\ndereference the freed cache_detail, walking a freed hash table.\n\nHold a reference on the struct net for the lifetime of the open\nfile descriptor. This prevents nfsd_net_exit() from running --\nand thus prevents nfsd_export_shutdown() from freeing the cache\n-- while any exports fd is open. cache_detail already stores\nits net pointer (cd-\u0026gt;net, set by cache_create_net()), so\nexports_release() can retrieve it without additional per-file\nstorage.(CVE-2026-31403)\n\nIn the Linux kernel, the Bluetooth SCO module\u0026apos;s sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn-\u0026gt;sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk-\u0026gt;sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)\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\nACPI: EC: clean up handlers on probe failure in acpi_ec_setup()\n\nWhen ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware\nplatforms, it has already started the EC and installed the address\nspace handler with the struct acpi_ec pointer as handler context.\nHowever, acpi_ec_setup() propagates the error without any cleanup.\n\nThe caller acpi_ec_add() then frees the struct acpi_ec for non-boot\ninstances, leaving a dangling handler context in ACPICA.\n\nAny subsequent AML evaluation that accesses an EC OpRegion field\ndispatches into acpi_ec_space_handler() with the freed pointer,\ncausing a use-after-free:\n\n BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)\n Write of size 8 at addr ffff88800721de38 by task init/1\n Call Trace:\n \u0026lt;TASK\u0026gt;\n mutex_lock (kernel/locking/mutex.c:289)\n acpi_ec_space_handler (drivers/acpi/ec.c:1362)\n acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)\n acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)\n acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)\n acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)\n acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)\n acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 1:\n acpi_ec_alloc (drivers/acpi/ec.c:1424)\n acpi_ec_add (drivers/acpi/ec.c:1692)\n\n Freed by task 1:\n kfree (mm/slub.c:6876)\n acpi_ec_add (drivers/acpi/ec.c:1751)\n\nThe bug triggers on reduced-hardware EC platforms (ec-\u0026gt;gpe \u0026lt; 0)\nwhen the GPIO IRQ provider defers probing. Once the stale handler\nexists, any unprivileged sysfs read that causes AML to touch an\nEC OpRegion (battery, thermal, backlight) exercises the dangling\npointer.\n\nFix this by calling ec_remove_handlers() in the error path of\nacpi_ec_setup() before clearing first_ec. ec_remove_handlers()\nchecks each EC_FLAGS_* bit before acting, so it is safe to call\nregardless of how far ec_install_handlers() progressed:\n\n -ENODEV (handler not installed): only calls acpi_ec_stop()\n -EPROBE_DEFER (handler installed): removes handler, stops EC(CVE-2026-31426)\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\nipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()\n\nWhen querying a nexthop object via RTM_GETNEXTHOP, the kernel currently\nallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for\nsingle nexthops and small Equal-Cost Multi-Path groups, this fixed\nallocation fails for large nexthop groups like 512 nexthops.\n\nThis results in the following warning splat:\n\n WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608\n [...]\n RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)\n netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n netlink_sendmsg (net/netlink/af_netlink.c:1894)\n ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)\n ___sys_sendmsg (net/socket.c:2641)\n __sys_sendmsg (net/socket.c:2671)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n \u0026lt;/TASK\u0026gt;\n\nFix this by allocating the size dynamically using nh_nlmsg_size() and\nusing nlmsg_new(), this is consistent with nexthop_notify() behavior. In\naddition, adjust nh_nlmsg_size_grp() so it calculates the size needed\nbased on flags passed. While at it, also add the size of NHA_FDB for\nnexthop group size calculation as it was missing too.\n\nThis cannot be reproduced via iproute2 as the group size is currently\nlimited and the command fails as follows:\n\naddattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)\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\nbridge: br_nd_send: validate ND option lengths\n\nbr_nd_send() walks ND options according to option-provided lengths.\nA malformed option can make the parser advance beyond the computed\noption 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-31752)\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\nserial: 8250: Fix TX deadlock when using DMA\n\n`dmaengine_terminate_async` does not guarantee that the\n`__dma_tx_complete` callback will run. The callback is currently the\nonly place where `dma-\u0026gt;tx_running` gets cleared. If the transaction is\ncanceled and the callback never runs, then `dma-\u0026gt;tx_running` will never\nget cleared and we will never schedule new TX DMA transactions again.\n\nThis change makes it so we clear `dma-\u0026gt;tx_running` after we terminate\nthe DMA transaction. This is \u0026quot;safe\u0026quot; because `serial8250_tx_dma_flush`\nis holding the UART port lock. The first thing the callback does is also\ngrab the UART port lock, so access to `dma-\u0026gt;tx_running` is serialized.(CVE-2026-43061)\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\nipv4: icmp: fix null-ptr-deref in icmp_build_probe()\n\nipv6_stub-\u0026gt;ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the\nIPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing\nthis error pointer to dev_hold() will cause a kernel crash with\nnull-ptr-deref.\n\nInstead, silently discard the request. RFC 8335 does not appear to\ndefine a specific response for the case where an IPv6 interface\nidentifier is syntactically valid but the implementation cannot perform\nthe lookup at runtime, and silently dropping the request may safer than\nmisreporting \u0026quot;No Such Interface\u0026quot;.(CVE-2026-43099)\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\nnet: usb: pegasus: enable basic endpoint checking\n\npegasus_probe() fills URBs with hardcoded endpoint pipes without\nverifying the endpoint descriptors:\n\n - usb_rcvbulkpipe(dev, 1) for RX data\n - usb_sndbulkpipe(dev, 2) for TX data\n - usb_rcvintpipe(dev, 3) for status interrupts\n\nA malformed USB device can present these endpoints with transfer types\nthat differ from what the driver assumes.\n\nAdd a pegasus_usb_ep enum for endpoint numbers, replacing magic\nconstants throughout. Add usb_check_bulk_endpoints() and\nusb_check_int_endpoints() calls before any resource allocation to\nverify endpoint types before use, rejecting devices with mismatched\ndescriptors at probe time, and avoid triggering assertion.\n\nSimilar fix to\n- commit 90b7f2961798 (\u0026quot;net: usb: rtl8150: enable basic endpoint checking\u0026quot;)\n- commit 9e7021d2aeae (\u0026quot;net: usb: catc: enable basic endpoint checking\u0026quot;)(CVE-2026-43156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/bitmap: fix GPF in write_page caused by resize race\n\nA General Protection Fault occurs in write_page() during array resize:\nRIP: 0010:write_page+0x22b/0x3c0 [md_mod]\n\nThis is a use-after-free race between bitmap_daemon_work() and\n__bitmap_resize(). The daemon iterates over `bitmap-\u0026gt;storage.filemap`\nwithout locking, while the resize path frees that storage via\nmd_bitmap_file_unmap(). `quiesce()` does not stop the md thread,\nallowing concurrent access to freed pages.\n\nFix by holding `mddev-\u0026gt;bitmap_info.mutex` during the bitmap update.(CVE-2026-43163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()\n\nOn the receive path, __ioam6_fill_trace_data() uses trace-\u0026gt;nodelen\nto decide how much data to write for each node. It trusts this field\nas-is from the incoming packet, with no consistency check against\ntrace-\u0026gt;type (the 24-bit field that tells which data items are\npresent). A crafted packet can set nodelen=0 while setting type bits\n0-21, causing the function to write ~100 bytes past the allocated\nregion (into skb_shared_info), which corrupts adjacent heap memory\nand leads to a kernel panic.\n\nAdd a shared helper ioam6_trace_compute_nodelen() in ioam6.c to\nderive the expected nodelen from the type field, and use it:\n\n - in ioam6_iptunnel.c (send path, existing validation) to replace\n the open-coded computation;\n - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose\n nodelen is inconsistent with the type field, before any data is\n written.\n\nPer RFC 9197, bits 12-21 are each short (4-octet) fields, so they\nare included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to\n0xff1ffc00).(CVE-2026-43186)\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\nx86/kexec: add a sanity check on previous kernel\u0026apos;s ima kexec buffer\n\nWhen the second-stage kernel is booted via kexec with a limiting command\nline such as \u0026quot;mem=\u0026lt;size\u0026gt;\u0026quot;, the physical range that contains the carried\nover IMA measurement list may fall outside the truncated RAM leading to a\nkernel panic.\n\n BUG: unable to handle page fault for address: ffff97793ff47000\n RIP: ima_restore_measurement_list+0xdc/0x45a\n #PF: error_code(0x0000) \u2013 not-present page\n\nOther architectures already validate the range with page_is_ram(), as done\nin commit cbf9c4b9617b (\u0026quot;of: check previous kernel\u0026apos;s ima-kexec-buffer\nagainst memory bounds\u0026quot;) do a similar check on x86.\n\nWithout carrying the measurement list across kexec, the attestation\nwould fail.(CVE-2026-43240)\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\next4: move ext4_percpu_param_init() before ext4_mb_init()\n\nWhen running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the\n`DOUBLE_CHECK` macro defined, the following panic is triggered:\n\n==================================================================\nEXT4-fs error (device vdc): ext4_validate_block_bitmap:423:\n comm mount: bg 0: bad block bitmap checksum\nBUG: unable to handle page fault for address: ff110000fa2cc000\nPGD 3e01067 P4D 3e02067 PUD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W\n 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)\nRIP: 0010:percpu_counter_add_batch+0x13/0xa0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_mark_group_bitmap_corrupted+0xcb/0xe0\n ext4_validate_block_bitmap+0x2a1/0x2f0\n ext4_read_block_bitmap+0x33/0x50\n mb_group_bb_bitmap_alloc+0x33/0x80\n ext4_mb_add_groupinfo+0x190/0x250\n ext4_mb_init_backend+0x87/0x290\n ext4_mb_init+0x456/0x640\n __ext4_fill_super+0x1072/0x1680\n ext4_fill_super+0xd3/0x280\n get_tree_bdev_flags+0x132/0x1d0\n vfs_get_tree+0x29/0xd0\n vfs_cmd_create+0x59/0xe0\n __do_sys_fsconfig+0x4f6/0x6b0\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n==================================================================\n\nThis issue can be reproduced using the following commands:\n mkfs.ext4 -F -q -b 1024 /dev/sda 5G\n tune2fs -O quota,project /dev/sda\n mount /dev/sda /tmp/test\n\nWith DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads\nand validates the block bitmap. When the validation fails,\next4_mark_group_bitmap_corrupted() attempts to update\nsbi-\u0026gt;s_freeclusters_counter. However, this percpu_counter has not been\ninitialized yet at this point, which leads to the panic described above.\n\nFix this by moving the execution of ext4_percpu_param_init() to occur\nbefore ext4_mb_init(), ensuring the per-CPU counters are initialized\nbefore they are used.(CVE-2026-43288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node\n\nWhen CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during\nvmalloc cleanup triggers expensive stack unwinding that acquires RCU read\nlocks. Processing a large purge_list without rescheduling can cause the\ntask to hold CPU for extended periods (10+ seconds), leading to RCU stalls\nand potential OOM conditions.\n\nThe issue manifests in purge_vmap_node() -\u0026gt; kasan_release_vmalloc_node()\nwhere iterating through hundreds or thousands of vmap_area entries and\nfreeing their associated shadow pages causes:\n\n rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l\n ...\n task:kworker/0:17 state:R running task stack:28840 pid:6229\n ...\n kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299\n purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299\n\nEach call to kasan_release_vmalloc() can free many pages, and with\npage_owner tracking, each free triggers save_stack() which performs stack\nunwinding under RCU read lock. Without yielding, this creates an\nunbounded RCU critical section.\n\nAdd periodic cond_resched() calls within the loop to allow:\n- RCU grace periods to complete\n- Other tasks to run\n- Scheduler to preempt when needed\n\nThe fix uses need_resched() for immediate response under load, with a\nbatch count of 32 as a guaranteed upper bound to prevent worst-case stalls\neven under light load.(CVE-2026-43292)\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\nio_uring/kbuf: check if target buffer list is still legacy on recycle\n\nThere\u0026apos;s a gap between when the buffer was grabbed and when it\npotentially gets recycled, where if the list is empty, someone could\u0026apos;ve\nupgraded it to a ring provided type. This can happen if the request\nis forced via io-wq. The legacy recycling is missing checking if the\nbuffer_list still exists, and if it\u0026apos;s of the correct type. Add those\nchecks.(CVE-2026-43366)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: prevent potential out-of-bounds reads in process_message_header()\n\nIf the message frame is (maliciously) corrupted in a way that the\nlength of the control segment ends up being less than the size of the\nmessage header or a different frame is made to look like a message\nframe, out-of-bounds reads may ensue in process_message_header().\n\nPerform an explicit bounds check before decoding the message header.(CVE-2026-43406)\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: class: cdc-wdm: fix reordering issue in read code path\n\nQuoting the bug report:\n\nDue to compiler optimization or CPU out-of-order execution, the\ndesc-\u0026gt;length update can be reordered before the memmove. If this\nhappens, wdm_read() can see the new length and call copy_to_user() on\nuninitialized memory. This also violates LKMM data race rules [1].\n\nFix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)\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:\n\nnet/mlx5: Fix deadlock between devlink lock and esw-\u0026gt;wq\n\nesw-\u0026gt;work_queue executes esw_functions_changed_event_handler -\u0026gt;\nesw_vfs_changed_event_handler and acquires the devlink lock.\n\n.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -\u0026gt;\nmlx5_devlink_eswitch_mode_set -\u0026gt; mlx5_eswitch_disable_locked -\u0026gt;\nmlx5_eswitch_event_handler_unregister -\u0026gt; flush_workqueue deadlocks\nwhen esw_vfs_changed_event_handler executes.\n\nFix that by no longer flushing the work to avoid the deadlock, and using\na generation counter to keep track of work relevance. This avoids an old\nhandler manipulating an esw that has undergone one or more mode changes:\n- the counter is incremented in mlx5_eswitch_event_handler_unregister.\n- the counter is read and passed to the ephemeral mlx5_host_work struct.\n- the work handler takes the devlink lock and bails out if the current\n generation is different than the one it was scheduled to operate on.\n- mlx5_eswitch_cleanup does the final draining before destroying the wq.\n\nNo longer flushing the workqueue has the side effect of maybe no longer\ncancelling pending vport_change_handler work items, but that\u0026apos;s ok since\nthose are disabled elsewhere:\n- mlx5_eswitch_disable_locked disables the vport eq notifier.\n- mlx5_esw_vport_disable disarms the HW EQ notification and marks\n vport-\u0026gt;enabled under state_lock to false to prevent pending vport\n handler from doing anything.\n- mlx5_eswitch_cleanup destroys the workqueue and makes sure all events\n are disabled/finished.(CVE-2026-43468)\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()\n\nAdd the same NULL guard already present in\nl2cap_sock_resume_cb() and l2cap_sock_ready_cb().(CVE-2026-45834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix slab-use-after-free in qd_put\n\nCommit a475c5dd16e5 (\u0026quot;gfs2: Free quota data objects synchronously\u0026quot;)\nstarted freeing quota data objects during filesystem shutdown instead of\nputting them back onto the LRU list, but it failed to remove these\nobjects from the LRU list, causing LRU list corruption. This caused\nuse-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access\nalready-freed objects on the LRU list.\n\nFix this by removing qd objects from the LRU list before freeing them in\nqd_put().\n\nInitial fix from Deepanshu Kartikey \u0026lt;(CVE-2026-45861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix role switching during resume\n\nIf the role change while we are suspended, the cdns3 driver switches to the\nnew mode during resume. However, switching to host mode in this context\ncauses a NULL pointer dereference.\n\nThe host role\u0026apos;s start() operation registers a xhci-hcd device, but its\nprobe is deferred while we are in the resume path. The host role\u0026apos;s resume()\noperation assumes the xhci-hcd device is already probed, which is not the\ncase, leading to the dereference. Since the start() operation of the new\nrole is already called, the resume operation can be skipped.\n\nSo skip the resume operation for the new role if a role switch occurs\nduring resume. Once the resume sequence is complete, the xhci-hcd device\ncan be probed in case of host mode.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000208\nMem abort info:\n...\nData abort info:\n...\n[0000000000000208] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] SMP\nModules linked in:\nCPU: 0 UID: 0 PID: 146 Comm: sh Not tainted\n6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT\nHardware name: Texas Instruments J7200 EVM (DT)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : usb_hcd_is_primary_hcd+0x0/0x1c\nlr : cdns_host_resume+0x24/0x5c\n...\nCall trace:\n usb_hcd_is_primary_hcd+0x0/0x1c (P)\n cdns_resume+0x6c/0xbc\n cdns3_controller_resume.isra.0+0xe8/0x17c\n cdns3_plat_resume+0x18/0x24\n platform_pm_resume+0x2c/0x68\n dpm_run_callback+0x90/0x248\n device_resume+0x100/0x24c\n dpm_resume+0x190/0x2ec\n dpm_resume_end+0x18/0x34\n suspend_devices_and_enter+0x2b0/0xa44\n pm_suspend+0x16c/0x5fc\n state_store+0x80/0xec\n kobj_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x130/0x1dc\n vfs_write+0x240/0x370\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0x108\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\nCode: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401)\n---[ end trace 0000000000000000 ]---(CVE-2026-45911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix inline data read failure for ztailpacking pclusters\n\nCompressed folios for ztailpacking pclusters must be valid before adding\nthese pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster()\nmay assume they are already valid and then trigger a NULL pointer\ndereference.\n\nIt is somewhat hard to reproduce because the inline data is in the same\nblock as the tail of the compressed indexes, which are usually read just\nbefore. However, it may still happen if a fatal signal arrives while\nread_mapping_folio() is running, as shown below:\n\n erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008\n\n ...\n\n pc : z_erofs_decompress_queue+0x4c8/0xa14\n lr : z_erofs_decompress_queue+0x160/0xa14\n sp : ffffffc08b3eb3a0\n x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000\n x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001\n x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700\n x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098\n x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004\n x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9\n x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f\n x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020\n x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n z_erofs_decompress_queue+0x4c8/0xa14\n z_erofs_runqueue+0x908/0x97c\n z_erofs_read_folio+0x128/0x228\n filemap_read_folio+0x68/0x128\n filemap_get_pages+0x44c/0x8b4\n filemap_read+0x12c/0x5b8\n generic_file_read_iter+0x4c/0x15c\n do_iter_readv_writev+0x188/0x1e0\n vfs_iter_read+0xac/0x1a4\n backing_file_read_iter+0x170/0x34c\n ovl_read_iter+0xf0/0x140\n vfs_read+0x28c/0x344\n ksys_read+0x80/0xf0\n __arm64_sys_read+0x24/0x34\n invoke_syscall+0x60/0x114\n el0_svc_common+0x88/0xe4\n do_el0_svc+0x24/0x30\n el0_svc+0x40/0xa8\n el0t_64_sync_handler+0x70/0xbc\n el0t_64_sync+0x1bc/0x1c0\n\nFix this by reading the inline data before allocating and adding\nthe pclusters to the I/O chains.(CVE-2026-45943)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()\n\nIn amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM,\nthe function returns directly without releasing the allocated xcc_info,\nresulting in a memory leak.\n\nFix this by ensuring that xcc_info is properly freed in the error paths.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-45947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: fix memory leaks in gfs2_fill_super error path\n\nFix two memory leaks in the gfs2_fill_super() error handling path when\ntransitioning a filesystem to read-write mode fails.\n\nFirst leak: kthread objects (thread_struct, task_struct, etc.)\nWhen gfs2_freeze_lock_shared() fails after init_threads() succeeds, the\ncreated kernel threads (logd and quotad) are never destroyed. This\noccurs because the fail_per_node label doesn\u0026apos;t call\ngfs2_destroy_threads().\n\nSecond leak: quota bitmap buffer (8192 bytes)\nWhen gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but\nbefore other operations complete, the allocated quota bitmap is never\nfreed.\n\nThe fix moves thread cleanup to the fail_per_node label to handle all\nerror paths uniformly. gfs2_destroy_threads() is safe to call\nunconditionally as it checks for NULL pointers. Quota cleanup is added\nin gfs2_make_fs_rw() to properly handle the withdrawal case where\nquota initialization succeeds but the filesystem is then withdrawn.\n\nThread leak backtrace (gfs2_freeze_lock_shared failure):\n unreferenced object 0xffff88801d7bca80 (size 4480):\n copy_process+0x3a1/0x4670 kernel/fork.c:2422\n kernel_clone+0xf3/0x6e0 kernel/fork.c:2779\n kthread_create_on_node+0x100/0x150 kernel/kthread.c:478\n init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611\n gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265\n\nQuota leak backtrace (gfs2_make_fs_rw failure):\n unreferenced object 0xffff88812de7c000 (size 8192):\n gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409\n gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149\n gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()\n\nCover a missed execution path with a new check.(CVE-2026-45982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()\n\nSome crafted images can have illegal (!partial_decoding \u0026amp;\u0026amp;\nm_llen \u0026lt; m_plen) extents, and the LZ4 inplace decompression path\ncan be wrongly hit, but it cannot handle (outpages \u0026lt; inpages)\nproperly: \u0026quot;outpages - inpages\u0026quot; wraps to a large value and\nthe subsequent rq-\u0026gt;out[] access reads past the decompressed_pages\narray.\n\nHowever, such crafted cases can correctly result in a corruption\nreport in the normal LZ4 non-inplace path.\n\nLet\u0026apos;s add an additional check to fix this for backporting.\n\nReproducible image (base64-encoded gzipped blob):\n\nH4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g\ndilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i\nPNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz\n2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w\nywAAAAAAAADwu14ATsEYtgBQAAA=\n\n$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt\n$ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running. The Linux kernel CVE team has assigned CVE-2026-46044 to this issue.(CVE-2026-46044)\n\nIn the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -\u0026gt; list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe(). The Linux kernel CVE team has assigned CVE-2026-46051 to this issue.(CVE-2026-46051)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn\u0026apos;t intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it\u0026apos;s not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining \u0026quot;single\u0026quot; stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs] The Linux kernel CVE team has assigned CVE-2026-46076 to this issue.(CVE-2026-46076)\n\nIn the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff \u0026gt;= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com The Linux kernel CVE team has assigned CVE-2026-46078 to this issue.(CVE-2026-46078)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@] The Linux kernel CVE team has assigned CVE-2026-46082 to this issue.(CVE-2026-46082)\n\nIn the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: take vmap_purge_lock in shrinker decay_va_pool_node() can be invoked concurrently from two paths: __purge_vmap_area_lazy() when pools are being purged, and the shrinker via vmap_node_shrink_scan(). However, decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks. Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker path to ensure serialization with purge users. The Linux kernel CVE team has assigned CVE-2026-46093 to this issue.(CVE-2026-46093)\n\nIn the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lockPatch series \u0026quot;mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path\u0026quot;.Reads of \u0026apos;memcg_path\u0026apos; and \u0026apos;path\u0026apos; files in DAMON sysfs interface could racewith their writes, results in use-after-free. Fix those.This patch (of 2):damon_sysfs_scheme_filter-\u0026gt;mmecg_path can be read and written by users,via DAMON sysfs memcg_path file. It can also be indirectly read, for theparameters {on,off}line committing to DAMON. The reads for parameterscommitting are protected by damon_sysfs_lock to avoid the sysfs filesbeing destroyed while any of the parameters are being read. But theuser-driven direct reads and writes are not protected by any lock, whilethe write is deallocating the memcg_path-pointing buffer. As a result,the readers could read the already freed buffer (user-after-free). Notethat the user-reads don\u0026apos;t race when the same open file is used by thewriter, due to kernfs\u0026apos;s open file locking. Nonetheless, doing the readsand writes with separate open files would be common. Fix it by protectingboth the user-direct reads and writes with damon_sysfs_lock.(CVE-2026-46121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt\n\nhci_le_create_big_complete_evt() iterates over BT_BOUND connections for\na BIG handle using a while loop, accessing ev-\u0026gt;bis_handle[i++] on each\niteration. However, there is no check that i stays within ev-\u0026gt;num_bis\nbefore the array access.\n\nWhen a controller sends a LE_Create_BIG_Complete event with fewer\nbis_handle entries than there are BT_BOUND connections for that BIG,\nor with num_bis=0, the loop reads beyond the valid bis_handle[] flex\narray into adjacent heap memory. Since the out-of-bounds values\ntypically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()\nrejects them and the connection remains in BT_BOUND state. The same\nconnection is then found again by hci_conn_hash_lookup_big_state(),\ncreating an infinite loop with hci_dev_lock held.\n\nFix this by terminating the BIG if in case not all BIS could be setup\nproperly.(CVE-2026-46138)\n\nIn the Linux kernel, vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. The rtnl_delete_link() must happen under RTNL and cannot be executed in RCU context. Calling synchronize_net() while holding RTNL is not good for performance and system stability, so calling netdev_put() in RCU call is the right solution. However, when the device is deleted, rtnl_unlock() calls netdev_run_todo() and blocks until all references are gone. In the current code, this means that call_rcu() is never reached, the vport is never freed, and the reference is never released, causing a self-deadlock on device removal. The fix moves the rcu_call() before rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from rtnl_unlock()-\u0026gt;netdev_run_todo() while RTNL itself is already released.(CVE-2026-46165)\n\nIn the Linux kernel\u0026apos;s RISC-V KVM subsystem, when the second kzalloc (host_context.vector.datap) fails in kvm_riscv_vcpu_alloc_vector_context, the first allocation (guest_context.vector.datap) is not freed, causing a memory leak. An attacker can trigger this via ioctl(vm_fd, KVM_CREATE_VCPU), potentially leading to resource exhaustion.(CVE-2026-46171)\n\nIn the Linux kernel, the mlx4_ib_create_srq() function fails to release resources allocated by mlx4_srq_alloc() in error handling paths, leading to a resource leak. An attacker could exploit this vulnerability to cause resource exhaustion or denial of service.(CVE-2026-46178)\n\nIn the Linux kernel, the spi_nor_params_show() function uses sizeof(snor_f_names) to calculate the array length. Since snor_f_names is an array of pointers, sizeof returns the total byte size of the pointer array (element_count sizeof(void )), which on 64-bit systems is 8 times larger than intended. This causes an out-of-bounds read when a flag bit is set that exceeds the actual element count but falls within the inflated byte-size count. The fix replaces sizeof with ARRAY_SIZE to pass the actual number of elements.(CVE-2026-46190)",
"id": "OESA-2026-2582",
"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-2582"
},
{
"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-68801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71130"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23074"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23100"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23269"
},
{
"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-23378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23406"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23410"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23411"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23439"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23441"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23444"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23448"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23461"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23473"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23475"
},
{
"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-31399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31400"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31403"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31408"
},
{
"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-31426"
},
{
"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-31531"
},
{
"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-31752"
},
{
"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-43061"
},
{
"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-43099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43163"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43186"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43212"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43240"
},
{
"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-43288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43292"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43345"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43406"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43419"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43468"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43493"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43503"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45943"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46121"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46165"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46190"
}
],
"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-39833",
"CVE-2025-68334",
"CVE-2025-68340",
"CVE-2025-68801",
"CVE-2025-71068",
"CVE-2025-71087",
"CVE-2025-71130",
"CVE-2025-71152",
"CVE-2025-71194",
"CVE-2026-23001",
"CVE-2026-23011",
"CVE-2026-23025",
"CVE-2026-23054",
"CVE-2026-23074",
"CVE-2026-23100",
"CVE-2026-23138",
"CVE-2026-23247",
"CVE-2026-23269",
"CVE-2026-23272",
"CVE-2026-23312",
"CVE-2026-23340",
"CVE-2026-23378",
"CVE-2026-23389",
"CVE-2026-23406",
"CVE-2026-23407",
"CVE-2026-23410",
"CVE-2026-23411",
"CVE-2026-23439",
"CVE-2026-23440",
"CVE-2026-23441",
"CVE-2026-23444",
"CVE-2026-23448",
"CVE-2026-23450",
"CVE-2026-23452",
"CVE-2026-23461",
"CVE-2026-23473",
"CVE-2026-23475",
"CVE-2026-31392",
"CVE-2026-31398",
"CVE-2026-31399",
"CVE-2026-31400",
"CVE-2026-31403",
"CVE-2026-31408",
"CVE-2026-31421",
"CVE-2026-31422",
"CVE-2026-31426",
"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-31531",
"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-31752",
"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-43061",
"CVE-2026-43064",
"CVE-2026-43079",
"CVE-2026-43099",
"CVE-2026-43148",
"CVE-2026-43156",
"CVE-2026-43163",
"CVE-2026-43186",
"CVE-2026-43212",
"CVE-2026-43240",
"CVE-2026-43262",
"CVE-2026-43273",
"CVE-2026-43288",
"CVE-2026-43292",
"CVE-2026-43345",
"CVE-2026-43366",
"CVE-2026-43406",
"CVE-2026-43419",
"CVE-2026-43427",
"CVE-2026-43428",
"CVE-2026-43468",
"CVE-2026-43493",
"CVE-2026-43503",
"CVE-2026-45834",
"CVE-2026-45861",
"CVE-2026-45911",
"CVE-2026-45943",
"CVE-2026-45947",
"CVE-2026-45961",
"CVE-2026-45982",
"CVE-2026-45999",
"CVE-2026-46044",
"CVE-2026-46051",
"CVE-2026-46076",
"CVE-2026-46078",
"CVE-2026-46082",
"CVE-2026-46093",
"CVE-2026-46121",
"CVE-2026-46138",
"CVE-2026-46165",
"CVE-2026-46171",
"CVE-2026-46178",
"CVE-2026-46190"
]
}
OPENSUSE-SU-2026:20287-1
Vulnerability from csaf_opensuse - Published: 2026-02-27 13:03 - Updated: 2026-09-17 17:27SUSE-SU-2026:0447-1
Vulnerability from csaf_suse - Published: 2026-02-11 14:05 - Updated: 2026-02-11 14:05SUSE-SU-2026:0472-1
Vulnerability from csaf_suse - Published: 2026-02-12 11:26 - Updated: 2026-02-12 11:26Sightings
| 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.