Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-40102 (GCVE-0-2025-40102)
Vulnerability from cvelistv5 – Published: 2025-10-30 09:48 – Updated: 2026-09-02 12:49| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
b7b27facc7b50a5fce0afaa3df56157136ce181a , < b0ab34a9e4cd5b88b522cc156e792cefe3085334
(git)
Affected: b7b27facc7b50a5fce0afaa3df56157136ce181a , < d64461d38972302f0243498ff409b0d54e14e106 (git) Affected: b7b27facc7b50a5fce0afaa3df56157136ce181a , < b498f0da45a388b40195f7198455c62fe366a372 (git) Affected: b7b27facc7b50a5fce0afaa3df56157136ce181a , < 7b854e68365a84dfa984ee81268e10b9311ac9d2 (git) Affected: b7b27facc7b50a5fce0afaa3df56157136ce181a , < c0fcd72e7eb50205dc20731033b0b1c67ecbe4dc (git) Affected: b7b27facc7b50a5fce0afaa3df56157136ce181a , < 64a04e6320fc5affbadc59dc7024d79f909bfe84 (git) Affected: b7b27facc7b50a5fce0afaa3df56157136ce181a , < 0aa1b76fe1429629215a7c79820e4b96233ac4a3 (git) |
guessed | |
| Linux | Linux |
Affected:
4.19
Unaffected: 0 , < 4.19 (semver) Unaffected: 5.10.269 , ≤ 5.10.* (semver) Unaffected: 5.15.220 , ≤ 5.15.* (semver) Unaffected: 6.1.187 , ≤ 6.1.* (semver) Unaffected: 6.6.156 , ≤ 6.6.* (semver) Unaffected: 6.12.108 , ≤ 6.12.* (semver) Unaffected: 6.17.5 , ≤ 6.17.* (semver) Unaffected: 6.18 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm64/kvm/arm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b0ab34a9e4cd5b88b522cc156e792cefe3085334",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "d64461d38972302f0243498ff409b0d54e14e106",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "b498f0da45a388b40195f7198455c62fe366a372",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "7b854e68365a84dfa984ee81268e10b9311ac9d2",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "c0fcd72e7eb50205dc20731033b0b1c67ecbe4dc",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "64a04e6320fc5affbadc59dc7024d79f909bfe84",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "0aa1b76fe1429629215a7c79820e4b96233ac4a3",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm64/kvm/arm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.19"
},
{
"lessThan": "4.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.269",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.220",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.187",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.156",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.108",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.269",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.220",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.187",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.156",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.108",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.5",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "4.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0027t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0027ve been\nthrown away by the eventual reset of the vCPU\u0027s state."
}
],
"providerMetadata": {
"dateUpdated": "2026-09-02T12:49:25.880Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b0ab34a9e4cd5b88b522cc156e792cefe3085334"
},
{
"url": "https://git.kernel.org/stable/c/d64461d38972302f0243498ff409b0d54e14e106"
},
{
"url": "https://git.kernel.org/stable/c/b498f0da45a388b40195f7198455c62fe366a372"
},
{
"url": "https://git.kernel.org/stable/c/7b854e68365a84dfa984ee81268e10b9311ac9d2"
},
{
"url": "https://git.kernel.org/stable/c/c0fcd72e7eb50205dc20731033b0b1c67ecbe4dc"
},
{
"url": "https://git.kernel.org/stable/c/64a04e6320fc5affbadc59dc7024d79f909bfe84"
},
{
"url": "https://git.kernel.org/stable/c/0aa1b76fe1429629215a7c79820e4b96233ac4a3"
}
],
"title": "KVM: arm64: Prevent access to vCPU events before init",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-40102",
"datePublished": "2025-10-30T09:48:07.790Z",
"dateReserved": "2025-04-16T07:20:57.164Z",
"dateUpdated": "2026-09-02T12:49:25.880Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-40102",
"date": "2026-09-30",
"epss": "0.00222",
"percentile": "0.11582"
},
"microsoft_vex": {
"current_release_date": "2026-09-23T02:22:59.000Z",
"cve": "CVE-2025-40102",
"id": "msrc_CVE-2025-40102",
"initial_release_date": "2025-10-31T01:09:59.000Z",
"product_status:known_affected": "18",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "KVM: arm64: Prevent access to vCPU events before init",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-40102.json",
"version": "18"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm64/kvm/arm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b0ab34a9e4cd5b88b522cc156e792cefe3085334",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "d64461d38972302f0243498ff409b0d54e14e106",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "b498f0da45a388b40195f7198455c62fe366a372",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "7b854e68365a84dfa984ee81268e10b9311ac9d2",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "c0fcd72e7eb50205dc20731033b0b1c67ecbe4dc",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "64a04e6320fc5affbadc59dc7024d79f909bfe84",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "0aa1b76fe1429629215a7c79820e4b96233ac4a3",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm64/kvm/arm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.19"
},
{
"lessThan": "4.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.269",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.220",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.187",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.156",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.108",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0027t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0027ve been\nthrown away by the eventual reset of the vCPU\u0027s state."
}
],
"id": "CVE-2025-40102",
"lastModified": "2026-09-02T13:16:50.197",
"metrics": {},
"published": "2025-10-30T10:15:34.603",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0aa1b76fe1429629215a7c79820e4b96233ac4a3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/64a04e6320fc5affbadc59dc7024d79f909bfe84"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7b854e68365a84dfa984ee81268e10b9311ac9d2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b0ab34a9e4cd5b88b522cc156e792cefe3085334"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b498f0da45a388b40195f7198455c62fe366a372"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c0fcd72e7eb50205dc20731033b0b1c67ecbe4dc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d64461d38972302f0243498ff409b0d54e14e106"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-30T10:28:02+00:00",
"cve": "CVE-2025-40102",
"id": "CVE-2025-40102",
"initial_release_date": "2025-10-30T00:00:00+00:00",
"product_status:known_affected": "232",
"product_status:known_not_affected": "42",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: Linux kernel KVM: Denial of Service due to uninitialized vCPU event handling",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-40102.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-08-30T01:49:09Z",
"cve": "CVE-2025-40102",
"id": "CVE-2025-40102",
"initial_release_date": "2025-10-31T00:24:58Z",
"product_status:first_fixed": "2",
"product_status:known_affected": "563",
"product_status:known_not_affected": "191",
"product_status:recommended": "481",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2025-40102",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-40102.json",
"version": "43"
}
}
}
FKIE_CVE-2025-40102
Vulnerability from fkie_nvd - Published: 2025-10-30 10:15 - Updated: 2026-09-02 13:16| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm64/kvm/arm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b0ab34a9e4cd5b88b522cc156e792cefe3085334",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "d64461d38972302f0243498ff409b0d54e14e106",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "b498f0da45a388b40195f7198455c62fe366a372",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "7b854e68365a84dfa984ee81268e10b9311ac9d2",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "c0fcd72e7eb50205dc20731033b0b1c67ecbe4dc",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "64a04e6320fc5affbadc59dc7024d79f909bfe84",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
},
{
"lessThan": "0aa1b76fe1429629215a7c79820e4b96233ac4a3",
"status": "affected",
"version": "b7b27facc7b50a5fce0afaa3df56157136ce181a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm64/kvm/arm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.19"
},
{
"lessThan": "4.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.269",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.220",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.187",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.156",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.108",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0027t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0027ve been\nthrown away by the eventual reset of the vCPU\u0027s state."
}
],
"id": "CVE-2025-40102",
"lastModified": "2026-09-02T13:16:50.197",
"metrics": {},
"published": "2025-10-30T10:15:34.603",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0aa1b76fe1429629215a7c79820e4b96233ac4a3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/64a04e6320fc5affbadc59dc7024d79f909bfe84"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7b854e68365a84dfa984ee81268e10b9311ac9d2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b0ab34a9e4cd5b88b522cc156e792cefe3085334"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b498f0da45a388b40195f7198455c62fe366a372"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c0fcd72e7eb50205dc20731033b0b1c67ecbe4dc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d64461d38972302f0243498ff409b0d54e14e106"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
GHSA-82MJ-RF9F-84H3
Vulnerability from github – Published: 2025-10-30 12:31 – Updated: 2026-09-02 15:33In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Prevent access to vCPU events before init
Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.
In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection:
kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.
{
"affected": [],
"aliases": [
"CVE-2025-40102"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-30T10:15:34Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0027t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0027ve been\nthrown away by the eventual reset of the vCPU\u0027s state.",
"id": "GHSA-82mj-rf9f-84h3",
"modified": "2026-09-02T15:33:18Z",
"published": "2025-10-30T12:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0aa1b76fe1429629215a7c79820e4b96233ac4a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64a04e6320fc5affbadc59dc7024d79f909bfe84"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b854e68365a84dfa984ee81268e10b9311ac9d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0ab34a9e4cd5b88b522cc156e792cefe3085334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b498f0da45a388b40195f7198455c62fe366a372"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0fcd72e7eb50205dc20731033b0b1c67ecbe4dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d64461d38972302f0243498ff409b0d54e14e106"
}
],
"schema_version": "1.4.0",
"severity": []
}
MSRC_CVE-2025-40102
Vulnerability from csaf_microsoft - Published: 2025-10-31 01:09 - Updated: 2026-09-23 02:22OESA-2025-2633 (CVE-2025-21991)
Vulnerability from osv_openeuler – Published: 2025-11-07 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: Some memory may share the same node as a CPU, and others are provided as memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type unsigned long[512] [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. bp: Massage commit message, fix typo.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: avoid NPD when ASIC does not support DMUB
ctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is tested in dm_dmub_sw_init.
However, it will be dereferenced in dmub_hw_lock_mgr_cmd if should_use_dmub_lock returns true.
This has been the case since dmub support has been added for PSR1.
Fix this by checking for dmub_srv in should_use_dmub_lock.
[ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 37.447808] #PF: supervisor read access in kernel mode [ 37.452959] #PF: error_code(0x0000) - not-present page [ 37.458112] PGD 0 P4D 0 [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88 [ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.572697] Call Trace: [ 37.575152] <TASK> [ 37.577258] ? __die_body+0x66/0xb0 [ 37.580756] ? page_fault_oops+0x3e7/0x4a0 [ 37.584861] ? exc_page_fault+0x3e/0xe0 [ 37.588706] ? exc_page_fault+0x5c/0xe0 [ 37.592550] ? asm_exc_page_fault+0x22/0x30 [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.601107] dcn10_cursor_lock+0x1e1/0x240 [ 37.605211] program_cursor_attributes+0x81/0x190 [ 37.609923] commit_planes_for_stream+0x998/0x1ef0 [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0 [ 37.619703] dc_update_planes_and_stream+0x78/0x140 [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0 [ 37.629832] ? srso_return_thunk+0x5/0x5f [ 37.633847] ? mark_held_locks+0x6d/0xd0 [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50 [ 37.642135] ? srso_return_thunk+0x5/0x5f [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150 [ 37.650510] ? srso_return_thunk+0x5/0x5f [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50 [ 37.658883] ? srso_return_thunk+0x5/0x5f [ 37.662897] ? wait_for_common+0x186/0x1c0 [ 37.666998] ? srso_return_thunk+0x5/0x5f [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170 [ 37.675983] commit_tail+0xf5/0x1c0 [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0 [ 37.684186] drm_atomic_commit+0xd6/0x100 [ 37.688199] ? __cfidrmprintfn_info+0x10/0x10 [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130 [ 37.698054] drm_mode_cursor_common+0x501/0x670 [ 37.702600] ? cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70 [ 37.711851] drm_ioctl_kernel+0xf2/0x150 [ 37.715781] drm_ioctl+0x363/0x590 [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.724165] amdgpu_drm_ioctl+0x41/0x80 [ 37.728013] __se_sys_ioctl+0x7f/0xd0 [ 37.731685] do_syscall_64+0x87/0x100 [ 37.735355] ? vma_end_read+0x12/0xe0 [ 37.739024] ? srso_return_thunk+0x5/0x5f [ 37.743041] ? find_held_lock+0x47/0xf0 [ 37.746884] ? vma_end_read+0x12/0xe0 [ 37.750552] ? srso_return_thunk+0x5/0 ---truncated---(CVE-2025-22093)
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: Fix unsafe attribute parsing in output_userspace()
This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.(CVE-2025-37998)
In the Linux kernel, the following vulnerability has been resolved:
comedi: pcl726: Prevent invalid irq number
The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob.
Added an interrupt number check to prevent users from passing in an irq number that was too large.
If it->options[1] is 31, then 1 << it->options[1] is still invalid
because it shifts a 1-bit into the sign bit (which is UB in C).
Possible solutions include reducing the upper bound on the
it->options[1] value to 30 or lower, or using 1U << it->options[1].
The old code would just not attempt to request the IRQ if the
options[1] value were invalid. And it would still configure the
device without interrupts even if the call to request_irq returned an
error. So it would be better to combine this test with the test below.(CVE-2025-39685)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: pfr_update: Fix the driver update version check
The security-version-number check should be used rather than the runtime version check for driver updates.
Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one.
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list
In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache.
Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again.
This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows:
cpu0 cpu1 shrink_folio_list memory_failure TestSetPageHWPoison unmap_poisoned_folio --> trigger BUG_ON due to unmap_poisoned_folio couldn't handle large folio
[(CVE-2025-39725)
In the Linux kernel, the following vulnerability has been resolved:
RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()
The function divides number of online CPUs by num_core_siblings, and later checks the divider by zero. This implies a possibility to get and divide-by-zero runtime error. Fix it by moving the check prior to division. This also helps to save one indentation level.(CVE-2025-39742)
In the Linux kernel, the following vulnerability has been resolved:
jbd2: prevent softlockup in jbd2_log_do_checkpoint()
Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant.
jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.
watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20
So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup.(CVE-2025-39782)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix lockdep assertion on sync reset unload event
Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning.
Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: <TASK> mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2025-39832)
In the Linux kernel, the following vulnerability has been resolved:
ppp: fix memory leak in pad_compress_skb
If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does:
skb = pad_compress_skb(ppp, skb);
if (!skb)
goto drop;
drop: kfree_skb(skb);
When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.
Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails.(CVE-2025-39847)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
syzbot reported the splat below without a repro.
In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that.
The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit.
bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release().
Two threads could see the same socket during the list iteration in bt_accept_dequeue():
CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF
Depending on the timing, the other thread could show up in the "Freed by task" part.
Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release().
[0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK>
Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---(CVE-2025-39860)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix invalid accesses to ceph_connection_v1_info
There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use).
On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets.
con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.(CVE-2025-39880)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: Check encryption key size on incoming connection
This is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bit
This tests the security key with size from 1 to 15 bytes while the Security Mode 4 Level 4 requests 16 bytes key size.
Currently PTS fails with the following logs: - expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt), but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information available
And HCI logs: < HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7 > ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64 < ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)(CVE-2025-39889)
In the Linux kernel, the following vulnerability has been resolved:
cnic: Fix use-after-free bugs in cnic_delete_task
The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task().
A typical race condition is illustrated below:
CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | / the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed.
This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.(CVE-2025-39945)
In the Linux kernel, the following vulnerability has been resolved:
qed: Don't collect too many protection override GRC elements
In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer.
This will result in a kernel panic with reason:
BUG: unable to handle kernel paging request at ADDRESS
where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure.
The panic can be arrived at from either the qede Ethernet driver path:
[exception RIP: qed_grc_dump_addr_range+0x108]
qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783
or the qedf storage driver path:
[exception RIP: qed_grc_dump_addr_range+0x108]
qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663
Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.(CVE-2025-39949)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix validation of VF state in get resources
VF state I40E_VF_STATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources.
Use I40E_VF_STATE_RESOURCES_LOADED that is set only in i40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix input validation logic for action_meta
Fix condition to check 'greater or equal' to prevent OOB dereference.(CVE-2025-39970)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix idx validation in i40e_validate_queue_map
Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)
In the Linux kernel, the following vulnerability has been resolved:
i40e: add validation for ring_len param
The ring_len parameter provided by the virtual function (VF)
is assigned directly to the hardware memory context (HMC) without
any validation.
To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)
In the Linux kernel, the following vulnerability has been resolved:
futex: Prevent use-after-free during requeue-PI
syzbot managed to trigger the following race:
T1 T2
futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() / preempt /
* timeout/ signal wakes T1 *
futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage
/* back */
wake_up_state(q->task, TASK_NORMAL);
In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization.
This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section.
Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated.
Read futex_q::task before updating the requeue state, use it for the following wakeup.(CVE-2025-39977)
In the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)
In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)
There is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call->perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)
In the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)
In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)
In the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (>= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-source-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"perf-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"python3-perf-6.6.0-115.0.0.108.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-115.0.0.108.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-115.0.0.108.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-source-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"perf-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"python3-perf-6.6.0-115.0.0.108.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-115.0.0.108.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-115.0.0.108.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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: Some memory may share the same node as a CPU, and others are provided as memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type unsigned long[512] [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ](CVE-2025-21991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid NPD when ASIC does not support DMUB\n\nctx-\u0026gt;dmub_srv will de NULL if the ASIC does not support DMUB, which is\ntested in dm_dmub_sw_init.\n\nHowever, it will be dereferenced in dmub_hw_lock_mgr_cmd if\nshould_use_dmub_lock returns true.\n\nThis has been the case since dmub support has been added for PSR1.\n\nFix this by checking for dmub_srv in should_use_dmub_lock.\n\n[ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058\n[ 37.447808] #PF: supervisor read access in kernel mode\n[ 37.452959] #PF: error_code(0x0000) - not-present page\n[ 37.458112] PGD 0 P4D 0\n[ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88\n[ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0\n[ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 \u0026lt;48\u0026gt; 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5\n[ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202\n[ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358\n[ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000\n[ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5\n[ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000\n[ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000\n[ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000\n[ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0\n[ 37.572697] Call Trace:\n[ 37.575152] \u0026lt;TASK\u0026gt;\n[ 37.577258] ? __die_body+0x66/0xb0\n[ 37.580756] ? page_fault_oops+0x3e7/0x4a0\n[ 37.584861] ? exc_page_fault+0x3e/0xe0\n[ 37.588706] ? exc_page_fault+0x5c/0xe0\n[ 37.592550] ? asm_exc_page_fault+0x22/0x30\n[ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0\n[ 37.601107] dcn10_cursor_lock+0x1e1/0x240\n[ 37.605211] program_cursor_attributes+0x81/0x190\n[ 37.609923] commit_planes_for_stream+0x998/0x1ef0\n[ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0\n[ 37.619703] dc_update_planes_and_stream+0x78/0x140\n[ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0\n[ 37.629832] ? srso_return_thunk+0x5/0x5f\n[ 37.633847] ? mark_held_locks+0x6d/0xd0\n[ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50\n[ 37.642135] ? srso_return_thunk+0x5/0x5f\n[ 37.646148] ? lockdep_hardirqs_on+0x95/0x150\n[ 37.650510] ? srso_return_thunk+0x5/0x5f\n[ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50\n[ 37.658883] ? srso_return_thunk+0x5/0x5f\n[ 37.662897] ? wait_for_common+0x186/0x1c0\n[ 37.666998] ? srso_return_thunk+0x5/0x5f\n[ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170\n[ 37.675983] commit_tail+0xf5/0x1c0\n[ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0\n[ 37.684186] drm_atomic_commit+0xd6/0x100\n[ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10\n[ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130\n[ 37.698054] drm_mode_cursor_common+0x501/0x670\n[ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[ 37.707572] drm_mode_cursor_ioctl+0x48/0x70\n[ 37.711851] drm_ioctl_kernel+0xf2/0x150\n[ 37.715781] drm_ioctl+0x363/0x590\n[ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[ 37.724165] amdgpu_drm_ioctl+0x41/0x80\n[ 37.728013] __se_sys_ioctl+0x7f/0xd0\n[ 37.731685] do_syscall_64+0x87/0x100\n[ 37.735355] ? vma_end_read+0x12/0xe0\n[ 37.739024] ? srso_return_thunk+0x5/0x5f\n[ 37.743041] ? find_held_lock+0x47/0xf0\n[ 37.746884] ? vma_end_read+0x12/0xe0\n[ 37.750552] ? srso_return_thunk+0x5/0\n---truncated---(CVE-2025-22093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix unsafe attribute parsing in output_userspace()\n\nThis patch replaces the manual Netlink attribute iteration in\noutput_userspace() with nla_for_each_nested(), which ensures that only\nwell-formed attributes are processed.(CVE-2025-37998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: pcl726: Prevent invalid irq number\n\nThe reproducer passed in an irq number(0x80008000) that was too large,\nwhich triggered the oob.\n\nAdded an interrupt number check to prevent users from passing in an irq\nnumber that was too large.\n\nIf `it-\u0026gt;options[1]` is 31, then `1 \u0026lt;\u0026lt; it-\u0026gt;options[1]` is still invalid\nbecause it shifts a 1-bit into the sign bit (which is UB in C).\nPossible solutions include reducing the upper bound on the\n`it-\u0026gt;options[1]` value to 30 or lower, or using `1U \u0026lt;\u0026lt; it-\u0026gt;options[1]`.\n\nThe old code would just not attempt to request the IRQ if the\n`options[1]` value were invalid. And it would still configure the\ndevice without interrupts even if the call to `request_irq` returned an\nerror. So it would be better to combine this test with the test below.(CVE-2025-39685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: pfr_update: Fix the driver update version check\n\nThe security-version-number check should be used rather\nthan the runtime version check for driver updates.\n\nOtherwise, the firmware update would fail when the update binary had\na lower runtime version number than the current one.\n\n[ rjw: Changelog edits ](CVE-2025-39701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough. memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic. The race is as\nfollows:\n\ncpu0 cpu1\n shrink_folio_list memory_failure\n TestSetPageHWPoison\n unmap_poisoned_folio\n --\u0026gt; trigger BUG_ON due to\n unmap_poisoned_folio couldn\u0026apos;t\n handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()\n\nThe function divides number of online CPUs by num_core_siblings, and\nlater checks the divider by zero. This implies a possibility to get\nand divide-by-zero runtime error. Fix it by moving the check prior to\ndivision. This also helps to save one indentation level.(CVE-2025-39742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix lockdep assertion on sync reset unload event\n\nFix lockdep assertion triggered during sync reset unload event. When the\nsync reset flow is initiated using the devlink reload fw_activate\noption, the PF already holds the devlink lock while handling unload\nevent. In this case, delegate sync reset unload event handling back to\nthe devlink callback process to avoid double-locking and resolve the\nlockdep warning.\n\nKernel log:\nWARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40\n[...]\nCall Trace:\n\u0026lt;TASK\u0026gt;\n mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]\n mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]\n process_one_work+0x222/0x640\n worker_thread+0x199/0x350\n kthread+0x10b/0x230\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x8e/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2025-39832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix memory leak in pad_compress_skb\n\nIf alloc_skb() fails in pad_compress_skb(), it returns NULL without\nreleasing the old skb. The caller does:\n\n skb = pad_compress_skb(ppp, skb);\n if (!skb)\n goto drop;\n\ndrop:\n kfree_skb(skb);\n\nWhen pad_compress_skb() returns NULL, the reference to the old skb is\nlost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.\n\nAlign pad_compress_skb() semantics with realloc(): only free the old\nskb if allocation and compression succeed. At the call site, use the\nnew_skb variable so the original skb is not lost when pad_compress_skb()\nfails.(CVE-2025-39847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n CPU1 CPU2 (close())\n ---- ----\n sock_hold(sk) sock_hold(sk);\n lock_sock(sk) \u0026lt;-- block close()\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- refcnt by bt_accept_enqueue()\n release_sock(sk)\n lock_sock(sk)\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- last refcnt\n bt_accept_unlink(sk) \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix invalid accesses to ceph_connection_v1_info\n\nThere is a place where generic code in messenger.c is reading and\nanother place where it is writing to con-\u0026gt;v1 union member without\nchecking that the union member is active (i.e. msgr1 is in use).\n\nOn 64-bit systems, con-\u0026gt;v1.auth_retry overlaps with con-\u0026gt;v2.out_iter,\nso such a read is almost guaranteed to return a bogus value instead of\n0 when msgr2 is in use. This ends up being fairly benign because the\nside effect is just the invalidation of the authorizer and successive\nfetching of new tickets.\n\ncon-\u0026gt;v1.connect_seq overlaps with con-\u0026gt;v2.conn_bufs and the fact that\nit\u0026apos;s being written to can cause more serious consequences, but luckily\nit\u0026apos;s not something that happens often.(CVE-2025-39880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Check encryption key size on incoming connection\n\nThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case:\n Security Mode 4 Level 4, Responder - Invalid Encryption Key Size\n - 128 bit\n\nThis tests the security key with size from 1 to 15 bytes while the\nSecurity Mode 4 Level 4 requests 16 bytes key size.\n\nCurrently PTS fails with the following logs:\n- expected:Connection Response:\n Code: [3 (0x03)] Code\n Identifier: (lt)WildCard: Exists(gt)\n Length: [8 (0x0008)]\n Destination CID: (lt)WildCard: Exists(gt)\n Source CID: [64 (0x0040)]\n Result: [3 (0x0003)] Connection refused - Security block\n Status: (lt)WildCard: Exists(gt),\nbut received:Connection Response:\n Code: [3 (0x03)] Code\n Identifier: [1 (0x01)]\n Length: [8 (0x0008)]\n Destination CID: [64 (0x0040)]\n Source CID: [64 (0x0040)]\n Result: [0 (0x0000)] Connection Successful\n Status: [0 (0x0000)] No further information available\n\nAnd HCI logs:\n\u0026lt; HCI Command: Read Encrypti.. (0x05|0x0008) plen 2\n Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n\u0026gt; HCI Event: Command Complete (0x0e) plen 7\n Read Encryption Key Size (0x05|0x0008) ncmd 1\n Status: Success (0x00)\n Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n Key size: 7\n\u0026gt; ACL Data RX: Handle 14 flags 0x02 dlen 12\n L2CAP: Connection Request (0x02) ident 1 len 4\n PSM: 4097 (0x1001)\n Source CID: 64\n\u0026lt; ACL Data TX: Handle 14 flags 0x00 dlen 16\n L2CAP: Connection Response (0x03) ident 1 len 8\n Destination CID: 64\n Source CID: 64\n Result: Connection successful (0x0000)\n Status: No further information available (0x0000)(CVE-2025-39889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup) | CPU 1 (delayed work callback)\ncnic_netdev_event() |\n cnic_stop_hw() | cnic_delete_task()\n cnic_cm_stop_bnx2x_hw() | ...\n cancel_delayed_work() | /* the queue_delayed_work()\n flush_workqueue() | executes after flush_workqueue()*/\n | queue_delayed_work()\n cnic_free_dev(dev)//free | cnic_delete_task() //new instance\n | dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays \u2014 such as inserting calls to ssleep()\nwithin the cnic_delete_task() function \u2014 to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don\u0026apos;t collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc\u0026apos;ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere \u0026quot;ADDRESS\u0026quot; is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn-\u0026gt;cdev-\u0026gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware\u0026apos;s return value to the maximum\nnumber of legal elements the firmware should return.(CVE-2025-39949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix validation of VF state in get resources\n\nVF state I40E_VF_STATE_ACTIVE is not the only state in which\nVF is actually active so it should not be used to determine\nif a VF is allowed to obtain resources.\n\nUse I40E_VF_STATE_RESOURCES_LOADED that is set only in\ni40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix input validation logic for action_meta\n\nFix condition to check \u0026apos;greater or equal\u0026apos; to prevent OOB dereference.(CVE-2025-39970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix idx validation in i40e_validate_queue_map\n\nEnsure idx is within range of active/initialized TCs when iterating over\nvf-\u0026gt;ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Prevent use-after-free during requeue-PI\n\nsyzbot managed to trigger the following race:\n\n T1 T2\n\n futex_wait_requeue_pi()\n futex_do_wait()\n schedule()\n futex_requeue()\n futex_proxy_trylock_atomic()\n futex_requeue_pi_prepare()\n requeue_pi_wake_futex()\n futex_requeue_pi_complete()\n /* preempt */\n\n * timeout/ signal wakes T1 *\n\n futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED\n futex_hash_put()\n // back to userland, on stack futex_q is garbage\n\n /* back */\n wake_up_state(q-\u0026gt;task, TASK_NORMAL);\n\nIn this scenario futex_wait_requeue_pi() is able to leave without using\nfutex_q::lock_ptr for synchronization.\n\nThis can be prevented by reading futex_q::task before updating the\nfutex_q::requeue_state. A reference on the task_struct is not needed\nbecause requeue_pi_wake_futex() is invoked with a spinlock_t held which\nimplies a RCU read section.\n\nEven if T1 terminates immediately after, the task_struct will remain valid\nduring T2\u0026apos;s wake_up_state(). A READ_ONCE on futex_q::task before\nfutex_requeue_pi_complete() is enough because it ensures that the variable\nis read before the state is updated.\n\nRead futex_q::task before updating the requeue state, use it for the\nfollowing wakeup.(CVE-2025-39977)\n\nIn the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)",
"id": "OESA-2025-2633",
"modified": "2026-08-06T11:09:45Z",
"published": "2025-11-07T11:09:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2633"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39701"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39742"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39970"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39972"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39977"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
}
],
"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-2025-21991",
"CVE-2025-22093",
"CVE-2025-37998",
"CVE-2025-39685",
"CVE-2025-39701",
"CVE-2025-39725",
"CVE-2025-39742",
"CVE-2025-39782",
"CVE-2025-39832",
"CVE-2025-39847",
"CVE-2025-39860",
"CVE-2025-39880",
"CVE-2025-39889",
"CVE-2025-39945",
"CVE-2025-39949",
"CVE-2025-39969",
"CVE-2025-39970",
"CVE-2025-39972",
"CVE-2025-39973",
"CVE-2025-39977",
"CVE-2025-40006",
"CVE-2025-40021",
"CVE-2025-40042",
"CVE-2025-40057",
"CVE-2025-40071",
"CVE-2025-40081",
"CVE-2025-40102"
]
}
OESA-2025-2634 (CVE-2025-21991)
Vulnerability from osv_openeuler – Published: 2025-11-07 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: Some memory may share the same node as a CPU, and others are provided as memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type unsigned long[512] [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. bp: Massage commit message, fix typo.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: avoid NPD when ASIC does not support DMUB
ctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is tested in dm_dmub_sw_init.
However, it will be dereferenced in dmub_hw_lock_mgr_cmd if should_use_dmub_lock returns true.
This has been the case since dmub support has been added for PSR1.
Fix this by checking for dmub_srv in should_use_dmub_lock.
[ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 37.447808] #PF: supervisor read access in kernel mode [ 37.452959] #PF: error_code(0x0000) - not-present page [ 37.458112] PGD 0 P4D 0 [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88 [ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.572697] Call Trace: [ 37.575152] <TASK> [ 37.577258] ? __die_body+0x66/0xb0 [ 37.580756] ? page_fault_oops+0x3e7/0x4a0 [ 37.584861] ? exc_page_fault+0x3e/0xe0 [ 37.588706] ? exc_page_fault+0x5c/0xe0 [ 37.592550] ? asm_exc_page_fault+0x22/0x30 [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.601107] dcn10_cursor_lock+0x1e1/0x240 [ 37.605211] program_cursor_attributes+0x81/0x190 [ 37.609923] commit_planes_for_stream+0x998/0x1ef0 [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0 [ 37.619703] dc_update_planes_and_stream+0x78/0x140 [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0 [ 37.629832] ? srso_return_thunk+0x5/0x5f [ 37.633847] ? mark_held_locks+0x6d/0xd0 [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50 [ 37.642135] ? srso_return_thunk+0x5/0x5f [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150 [ 37.650510] ? srso_return_thunk+0x5/0x5f [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50 [ 37.658883] ? srso_return_thunk+0x5/0x5f [ 37.662897] ? wait_for_common+0x186/0x1c0 [ 37.666998] ? srso_return_thunk+0x5/0x5f [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170 [ 37.675983] commit_tail+0xf5/0x1c0 [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0 [ 37.684186] drm_atomic_commit+0xd6/0x100 [ 37.688199] ? __cfidrmprintfn_info+0x10/0x10 [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130 [ 37.698054] drm_mode_cursor_common+0x501/0x670 [ 37.702600] ? cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70 [ 37.711851] drm_ioctl_kernel+0xf2/0x150 [ 37.715781] drm_ioctl+0x363/0x590 [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.724165] amdgpu_drm_ioctl+0x41/0x80 [ 37.728013] __se_sys_ioctl+0x7f/0xd0 [ 37.731685] do_syscall_64+0x87/0x100 [ 37.735355] ? vma_end_read+0x12/0xe0 [ 37.739024] ? srso_return_thunk+0x5/0x5f [ 37.743041] ? find_held_lock+0x47/0xf0 [ 37.746884] ? vma_end_read+0x12/0xe0 [ 37.750552] ? srso_return_thunk+0x5/0 ---truncated---(CVE-2025-22093)
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: Fix unsafe attribute parsing in output_userspace()
This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.(CVE-2025-37998)
In the Linux kernel, the following vulnerability has been resolved:
comedi: pcl726: Prevent invalid irq number
The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob.
Added an interrupt number check to prevent users from passing in an irq number that was too large.
If it->options[1] is 31, then 1 << it->options[1] is still invalid
because it shifts a 1-bit into the sign bit (which is UB in C).
Possible solutions include reducing the upper bound on the
it->options[1] value to 30 or lower, or using 1U << it->options[1].
The old code would just not attempt to request the IRQ if the
options[1] value were invalid. And it would still configure the
device without interrupts even if the call to request_irq returned an
error. So it would be better to combine this test with the test below.(CVE-2025-39685)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: pfr_update: Fix the driver update version check
The security-version-number check should be used rather than the runtime version check for driver updates.
Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one.
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list
In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache.
Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again.
This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows:
cpu0 cpu1 shrink_folio_list memory_failure TestSetPageHWPoison unmap_poisoned_folio --> trigger BUG_ON due to unmap_poisoned_folio couldn't handle large folio
[(CVE-2025-39725)
In the Linux kernel, the following vulnerability has been resolved:
RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()
The function divides number of online CPUs by num_core_siblings, and later checks the divider by zero. This implies a possibility to get and divide-by-zero runtime error. Fix it by moving the check prior to division. This also helps to save one indentation level.(CVE-2025-39742)
In the Linux kernel, the following vulnerability has been resolved:
jbd2: prevent softlockup in jbd2_log_do_checkpoint()
Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant.
jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.
watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20
So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup.(CVE-2025-39782)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix lockdep assertion on sync reset unload event
Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning.
Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: <TASK> mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2025-39832)
In the Linux kernel, the following vulnerability has been resolved:
ppp: fix memory leak in pad_compress_skb
If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does:
skb = pad_compress_skb(ppp, skb);
if (!skb)
goto drop;
drop: kfree_skb(skb);
When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.
Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails.(CVE-2025-39847)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
syzbot reported the splat below without a repro.
In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that.
The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit.
bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release().
Two threads could see the same socket during the list iteration in bt_accept_dequeue():
CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF
Depending on the timing, the other thread could show up in the "Freed by task" part.
Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release().
[0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK>
Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---(CVE-2025-39860)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix invalid accesses to ceph_connection_v1_info
There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use).
On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets.
con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.(CVE-2025-39880)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: Check encryption key size on incoming connection
This is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bit
This tests the security key with size from 1 to 15 bytes while the Security Mode 4 Level 4 requests 16 bytes key size.
Currently PTS fails with the following logs: - expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt), but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information available
And HCI logs: < HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7 > ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64 < ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)(CVE-2025-39889)
In the Linux kernel, the following vulnerability has been resolved:
cnic: Fix use-after-free bugs in cnic_delete_task
The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task().
A typical race condition is illustrated below:
CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | / the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed.
This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.(CVE-2025-39945)
In the Linux kernel, the following vulnerability has been resolved:
qed: Don't collect too many protection override GRC elements
In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer.
This will result in a kernel panic with reason:
BUG: unable to handle kernel paging request at ADDRESS
where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure.
The panic can be arrived at from either the qede Ethernet driver path:
[exception RIP: qed_grc_dump_addr_range+0x108]
qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783
or the qedf storage driver path:
[exception RIP: qed_grc_dump_addr_range+0x108]
qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663
Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.(CVE-2025-39949)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix validation of VF state in get resources
VF state I40E_VF_STATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources.
Use I40E_VF_STATE_RESOURCES_LOADED that is set only in i40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix input validation logic for action_meta
Fix condition to check 'greater or equal' to prevent OOB dereference.(CVE-2025-39970)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix idx validation in i40e_validate_queue_map
Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)
In the Linux kernel, the following vulnerability has been resolved:
i40e: add validation for ring_len param
The ring_len parameter provided by the virtual function (VF)
is assigned directly to the hardware memory context (HMC) without
any validation.
To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)
In the Linux kernel, the following vulnerability has been resolved:
futex: Prevent use-after-free during requeue-PI
syzbot managed to trigger the following race:
T1 T2
futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() / preempt /
* timeout/ signal wakes T1 *
futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage
/* back */
wake_up_state(q->task, TASK_NORMAL);
In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization.
This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section.
Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated.
Read futex_q::task before updating the requeue state, use it for the following wakeup.(CVE-2025-39977)
In the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)
In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)
There is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call->perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)
In the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)
In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)
In the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (>= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"perf-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-115.0.0.119.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-115.0.0.119.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"perf-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-115.0.0.119.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-115.0.0.119.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-115.0.0.119.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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: Some memory may share the same node as a CPU, and others are provided as memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type unsigned long[512] [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ](CVE-2025-21991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid NPD when ASIC does not support DMUB\n\nctx-\u0026gt;dmub_srv will de NULL if the ASIC does not support DMUB, which is\ntested in dm_dmub_sw_init.\n\nHowever, it will be dereferenced in dmub_hw_lock_mgr_cmd if\nshould_use_dmub_lock returns true.\n\nThis has been the case since dmub support has been added for PSR1.\n\nFix this by checking for dmub_srv in should_use_dmub_lock.\n\n[ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058\n[ 37.447808] #PF: supervisor read access in kernel mode\n[ 37.452959] #PF: error_code(0x0000) - not-present page\n[ 37.458112] PGD 0 P4D 0\n[ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88\n[ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0\n[ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 \u0026lt;48\u0026gt; 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5\n[ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202\n[ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358\n[ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000\n[ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5\n[ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000\n[ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000\n[ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000\n[ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0\n[ 37.572697] Call Trace:\n[ 37.575152] \u0026lt;TASK\u0026gt;\n[ 37.577258] ? __die_body+0x66/0xb0\n[ 37.580756] ? page_fault_oops+0x3e7/0x4a0\n[ 37.584861] ? exc_page_fault+0x3e/0xe0\n[ 37.588706] ? exc_page_fault+0x5c/0xe0\n[ 37.592550] ? asm_exc_page_fault+0x22/0x30\n[ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0\n[ 37.601107] dcn10_cursor_lock+0x1e1/0x240\n[ 37.605211] program_cursor_attributes+0x81/0x190\n[ 37.609923] commit_planes_for_stream+0x998/0x1ef0\n[ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0\n[ 37.619703] dc_update_planes_and_stream+0x78/0x140\n[ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0\n[ 37.629832] ? srso_return_thunk+0x5/0x5f\n[ 37.633847] ? mark_held_locks+0x6d/0xd0\n[ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50\n[ 37.642135] ? srso_return_thunk+0x5/0x5f\n[ 37.646148] ? lockdep_hardirqs_on+0x95/0x150\n[ 37.650510] ? srso_return_thunk+0x5/0x5f\n[ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50\n[ 37.658883] ? srso_return_thunk+0x5/0x5f\n[ 37.662897] ? wait_for_common+0x186/0x1c0\n[ 37.666998] ? srso_return_thunk+0x5/0x5f\n[ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170\n[ 37.675983] commit_tail+0xf5/0x1c0\n[ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0\n[ 37.684186] drm_atomic_commit+0xd6/0x100\n[ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10\n[ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130\n[ 37.698054] drm_mode_cursor_common+0x501/0x670\n[ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[ 37.707572] drm_mode_cursor_ioctl+0x48/0x70\n[ 37.711851] drm_ioctl_kernel+0xf2/0x150\n[ 37.715781] drm_ioctl+0x363/0x590\n[ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[ 37.724165] amdgpu_drm_ioctl+0x41/0x80\n[ 37.728013] __se_sys_ioctl+0x7f/0xd0\n[ 37.731685] do_syscall_64+0x87/0x100\n[ 37.735355] ? vma_end_read+0x12/0xe0\n[ 37.739024] ? srso_return_thunk+0x5/0x5f\n[ 37.743041] ? find_held_lock+0x47/0xf0\n[ 37.746884] ? vma_end_read+0x12/0xe0\n[ 37.750552] ? srso_return_thunk+0x5/0\n---truncated---(CVE-2025-22093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix unsafe attribute parsing in output_userspace()\n\nThis patch replaces the manual Netlink attribute iteration in\noutput_userspace() with nla_for_each_nested(), which ensures that only\nwell-formed attributes are processed.(CVE-2025-37998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: pcl726: Prevent invalid irq number\n\nThe reproducer passed in an irq number(0x80008000) that was too large,\nwhich triggered the oob.\n\nAdded an interrupt number check to prevent users from passing in an irq\nnumber that was too large.\n\nIf `it-\u0026gt;options[1]` is 31, then `1 \u0026lt;\u0026lt; it-\u0026gt;options[1]` is still invalid\nbecause it shifts a 1-bit into the sign bit (which is UB in C).\nPossible solutions include reducing the upper bound on the\n`it-\u0026gt;options[1]` value to 30 or lower, or using `1U \u0026lt;\u0026lt; it-\u0026gt;options[1]`.\n\nThe old code would just not attempt to request the IRQ if the\n`options[1]` value were invalid. And it would still configure the\ndevice without interrupts even if the call to `request_irq` returned an\nerror. So it would be better to combine this test with the test below.(CVE-2025-39685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: pfr_update: Fix the driver update version check\n\nThe security-version-number check should be used rather\nthan the runtime version check for driver updates.\n\nOtherwise, the firmware update would fail when the update binary had\na lower runtime version number than the current one.\n\n[ rjw: Changelog edits ](CVE-2025-39701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough. memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic. The race is as\nfollows:\n\ncpu0 cpu1\n shrink_folio_list memory_failure\n TestSetPageHWPoison\n unmap_poisoned_folio\n --\u0026gt; trigger BUG_ON due to\n unmap_poisoned_folio couldn\u0026apos;t\n handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()\n\nThe function divides number of online CPUs by num_core_siblings, and\nlater checks the divider by zero. This implies a possibility to get\nand divide-by-zero runtime error. Fix it by moving the check prior to\ndivision. This also helps to save one indentation level.(CVE-2025-39742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix lockdep assertion on sync reset unload event\n\nFix lockdep assertion triggered during sync reset unload event. When the\nsync reset flow is initiated using the devlink reload fw_activate\noption, the PF already holds the devlink lock while handling unload\nevent. In this case, delegate sync reset unload event handling back to\nthe devlink callback process to avoid double-locking and resolve the\nlockdep warning.\n\nKernel log:\nWARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40\n[...]\nCall Trace:\n\u0026lt;TASK\u0026gt;\n mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]\n mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]\n process_one_work+0x222/0x640\n worker_thread+0x199/0x350\n kthread+0x10b/0x230\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x8e/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2025-39832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix memory leak in pad_compress_skb\n\nIf alloc_skb() fails in pad_compress_skb(), it returns NULL without\nreleasing the old skb. The caller does:\n\n skb = pad_compress_skb(ppp, skb);\n if (!skb)\n goto drop;\n\ndrop:\n kfree_skb(skb);\n\nWhen pad_compress_skb() returns NULL, the reference to the old skb is\nlost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.\n\nAlign pad_compress_skb() semantics with realloc(): only free the old\nskb if allocation and compression succeed. At the call site, use the\nnew_skb variable so the original skb is not lost when pad_compress_skb()\nfails.(CVE-2025-39847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n CPU1 CPU2 (close())\n ---- ----\n sock_hold(sk) sock_hold(sk);\n lock_sock(sk) \u0026lt;-- block close()\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- refcnt by bt_accept_enqueue()\n release_sock(sk)\n lock_sock(sk)\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- last refcnt\n bt_accept_unlink(sk) \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix invalid accesses to ceph_connection_v1_info\n\nThere is a place where generic code in messenger.c is reading and\nanother place where it is writing to con-\u0026gt;v1 union member without\nchecking that the union member is active (i.e. msgr1 is in use).\n\nOn 64-bit systems, con-\u0026gt;v1.auth_retry overlaps with con-\u0026gt;v2.out_iter,\nso such a read is almost guaranteed to return a bogus value instead of\n0 when msgr2 is in use. This ends up being fairly benign because the\nside effect is just the invalidation of the authorizer and successive\nfetching of new tickets.\n\ncon-\u0026gt;v1.connect_seq overlaps with con-\u0026gt;v2.conn_bufs and the fact that\nit\u0026apos;s being written to can cause more serious consequences, but luckily\nit\u0026apos;s not something that happens often.(CVE-2025-39880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Check encryption key size on incoming connection\n\nThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case:\n Security Mode 4 Level 4, Responder - Invalid Encryption Key Size\n - 128 bit\n\nThis tests the security key with size from 1 to 15 bytes while the\nSecurity Mode 4 Level 4 requests 16 bytes key size.\n\nCurrently PTS fails with the following logs:\n- expected:Connection Response:\n Code: [3 (0x03)] Code\n Identifier: (lt)WildCard: Exists(gt)\n Length: [8 (0x0008)]\n Destination CID: (lt)WildCard: Exists(gt)\n Source CID: [64 (0x0040)]\n Result: [3 (0x0003)] Connection refused - Security block\n Status: (lt)WildCard: Exists(gt),\nbut received:Connection Response:\n Code: [3 (0x03)] Code\n Identifier: [1 (0x01)]\n Length: [8 (0x0008)]\n Destination CID: [64 (0x0040)]\n Source CID: [64 (0x0040)]\n Result: [0 (0x0000)] Connection Successful\n Status: [0 (0x0000)] No further information available\n\nAnd HCI logs:\n\u0026lt; HCI Command: Read Encrypti.. (0x05|0x0008) plen 2\n Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n\u0026gt; HCI Event: Command Complete (0x0e) plen 7\n Read Encryption Key Size (0x05|0x0008) ncmd 1\n Status: Success (0x00)\n Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n Key size: 7\n\u0026gt; ACL Data RX: Handle 14 flags 0x02 dlen 12\n L2CAP: Connection Request (0x02) ident 1 len 4\n PSM: 4097 (0x1001)\n Source CID: 64\n\u0026lt; ACL Data TX: Handle 14 flags 0x00 dlen 16\n L2CAP: Connection Response (0x03) ident 1 len 8\n Destination CID: 64\n Source CID: 64\n Result: Connection successful (0x0000)\n Status: No further information available (0x0000)(CVE-2025-39889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup) | CPU 1 (delayed work callback)\ncnic_netdev_event() |\n cnic_stop_hw() | cnic_delete_task()\n cnic_cm_stop_bnx2x_hw() | ...\n cancel_delayed_work() | /* the queue_delayed_work()\n flush_workqueue() | executes after flush_workqueue()*/\n | queue_delayed_work()\n cnic_free_dev(dev)//free | cnic_delete_task() //new instance\n | dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays \u2014 such as inserting calls to ssleep()\nwithin the cnic_delete_task() function \u2014 to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don\u0026apos;t collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc\u0026apos;ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere \u0026quot;ADDRESS\u0026quot; is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn-\u0026gt;cdev-\u0026gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware\u0026apos;s return value to the maximum\nnumber of legal elements the firmware should return.(CVE-2025-39949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix validation of VF state in get resources\n\nVF state I40E_VF_STATE_ACTIVE is not the only state in which\nVF is actually active so it should not be used to determine\nif a VF is allowed to obtain resources.\n\nUse I40E_VF_STATE_RESOURCES_LOADED that is set only in\ni40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix input validation logic for action_meta\n\nFix condition to check \u0026apos;greater or equal\u0026apos; to prevent OOB dereference.(CVE-2025-39970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix idx validation in i40e_validate_queue_map\n\nEnsure idx is within range of active/initialized TCs when iterating over\nvf-\u0026gt;ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Prevent use-after-free during requeue-PI\n\nsyzbot managed to trigger the following race:\n\n T1 T2\n\n futex_wait_requeue_pi()\n futex_do_wait()\n schedule()\n futex_requeue()\n futex_proxy_trylock_atomic()\n futex_requeue_pi_prepare()\n requeue_pi_wake_futex()\n futex_requeue_pi_complete()\n /* preempt */\n\n * timeout/ signal wakes T1 *\n\n futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED\n futex_hash_put()\n // back to userland, on stack futex_q is garbage\n\n /* back */\n wake_up_state(q-\u0026gt;task, TASK_NORMAL);\n\nIn this scenario futex_wait_requeue_pi() is able to leave without using\nfutex_q::lock_ptr for synchronization.\n\nThis can be prevented by reading futex_q::task before updating the\nfutex_q::requeue_state. A reference on the task_struct is not needed\nbecause requeue_pi_wake_futex() is invoked with a spinlock_t held which\nimplies a RCU read section.\n\nEven if T1 terminates immediately after, the task_struct will remain valid\nduring T2\u0026apos;s wake_up_state(). A READ_ONCE on futex_q::task before\nfutex_requeue_pi_complete() is enough because it ensures that the variable\nis read before the state is updated.\n\nRead futex_q::task before updating the requeue state, use it for the\nfollowing wakeup.(CVE-2025-39977)\n\nIn the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)",
"id": "OESA-2025-2634",
"modified": "2026-08-06T11:09:45Z",
"published": "2025-11-07T11:09:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2634"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39701"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39742"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39970"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39972"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39977"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
}
],
"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-2025-21991",
"CVE-2025-22093",
"CVE-2025-37998",
"CVE-2025-39685",
"CVE-2025-39701",
"CVE-2025-39725",
"CVE-2025-39742",
"CVE-2025-39782",
"CVE-2025-39832",
"CVE-2025-39847",
"CVE-2025-39860",
"CVE-2025-39880",
"CVE-2025-39889",
"CVE-2025-39945",
"CVE-2025-39949",
"CVE-2025-39969",
"CVE-2025-39970",
"CVE-2025-39972",
"CVE-2025-39973",
"CVE-2025-39977",
"CVE-2025-40006",
"CVE-2025-40021",
"CVE-2025-40042",
"CVE-2025-40057",
"CVE-2025-40071",
"CVE-2025-40081",
"CVE-2025-40102"
]
}
OESA-2025-2635 (CVE-2025-21991)
Vulnerability from osv_openeuler – Published: 2025-11-07 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: Some memory may share the same node as a CPU, and others are provided as memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type unsigned long[512] [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. bp: Massage commit message, fix typo.
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: Fix unsafe attribute parsing in output_userspace()
This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.(CVE-2025-37998)
In the Linux kernel, the following vulnerability has been resolved:
comedi: pcl726: Prevent invalid irq number
The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob.
Added an interrupt number check to prevent users from passing in an irq number that was too large.
If it->options[1] is 31, then 1 << it->options[1] is still invalid
because it shifts a 1-bit into the sign bit (which is UB in C).
Possible solutions include reducing the upper bound on the
it->options[1] value to 30 or lower, or using 1U << it->options[1].
The old code would just not attempt to request the IRQ if the
options[1] value were invalid. And it would still configure the
device without interrupts even if the call to request_irq returned an
error. So it would be better to combine this test with the test below.(CVE-2025-39685)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: pfr_update: Fix the driver update version check
The security-version-number check should be used rather than the runtime version check for driver updates.
Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one.
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list
In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache.
Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again.
This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows:
cpu0 cpu1 shrink_folio_list memory_failure TestSetPageHWPoison unmap_poisoned_folio --> trigger BUG_ON due to unmap_poisoned_folio couldn't handle large folio
[(CVE-2025-39725)
In the Linux kernel, the following vulnerability has been resolved:
RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()
The function divides number of online CPUs by num_core_siblings, and later checks the divider by zero. This implies a possibility to get and divide-by-zero runtime error. Fix it by moving the check prior to division. This also helps to save one indentation level.(CVE-2025-39742)
In the Linux kernel, the following vulnerability has been resolved:
jbd2: prevent softlockup in jbd2_log_do_checkpoint()
Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant.
jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.
watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20
So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup.(CVE-2025-39782)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix lockdep assertion on sync reset unload event
Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning.
Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: <TASK> mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2025-39832)
In the Linux kernel, the following vulnerability has been resolved:
ppp: fix memory leak in pad_compress_skb
If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does:
skb = pad_compress_skb(ppp, skb);
if (!skb)
goto drop;
drop: kfree_skb(skb);
When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.
Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails.(CVE-2025-39847)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
syzbot reported the splat below without a repro.
In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that.
The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit.
bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release().
Two threads could see the same socket during the list iteration in bt_accept_dequeue():
CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF
Depending on the timing, the other thread could show up in the "Freed by task" part.
Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release().
[0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK>
Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---(CVE-2025-39860)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix invalid accesses to ceph_connection_v1_info
There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use).
On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets.
con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.(CVE-2025-39880)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: Check encryption key size on incoming connection
This is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bit
This tests the security key with size from 1 to 15 bytes while the Security Mode 4 Level 4 requests 16 bytes key size.
Currently PTS fails with the following logs: - expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt), but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information available
And HCI logs: < HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7 > ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64 < ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)(CVE-2025-39889)
In the Linux kernel, the following vulnerability has been resolved:
cnic: Fix use-after-free bugs in cnic_delete_task
The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task().
A typical race condition is illustrated below:
CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | / the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed.
This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.(CVE-2025-39945)
In the Linux kernel, the following vulnerability has been resolved:
qed: Don't collect too many protection override GRC elements
In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer.
This will result in a kernel panic with reason:
BUG: unable to handle kernel paging request at ADDRESS
where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure.
The panic can be arrived at from either the qede Ethernet driver path:
[exception RIP: qed_grc_dump_addr_range+0x108]
qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783
or the qedf storage driver path:
[exception RIP: qed_grc_dump_addr_range+0x108]
qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663
Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.(CVE-2025-39949)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix validation of VF state in get resources
VF state I40E_VF_STATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources.
Use I40E_VF_STATE_RESOURCES_LOADED that is set only in i40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix input validation logic for action_meta
Fix condition to check 'greater or equal' to prevent OOB dereference.(CVE-2025-39970)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix idx validation in i40e_validate_queue_map
Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)
In the Linux kernel, the following vulnerability has been resolved:
i40e: add validation for ring_len param
The ring_len parameter provided by the virtual function (VF)
is assigned directly to the hardware memory context (HMC) without
any validation.
To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)
In the Linux kernel, the following vulnerability has been resolved:
futex: Prevent use-after-free during requeue-PI
syzbot managed to trigger the following race:
T1 T2
futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() / preempt /
* timeout/ signal wakes T1 *
futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage
/* back */
wake_up_state(q->task, TASK_NORMAL);
In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization.
This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section.
Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated.
Read futex_q::task before updating the requeue state, use it for the following wakeup.(CVE-2025-39977)
In the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)
In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)
There is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call->perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)
In the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)
In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)
In the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (>= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"perf-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-115.0.0.121.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-115.0.0.121.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"perf-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-115.0.0.121.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-115.0.0.121.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-115.0.0.121.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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: Some memory may share the same node as a CPU, and others are provided as memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type unsigned long[512] [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ](CVE-2025-21991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix unsafe attribute parsing in output_userspace()\n\nThis patch replaces the manual Netlink attribute iteration in\noutput_userspace() with nla_for_each_nested(), which ensures that only\nwell-formed attributes are processed.(CVE-2025-37998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: pcl726: Prevent invalid irq number\n\nThe reproducer passed in an irq number(0x80008000) that was too large,\nwhich triggered the oob.\n\nAdded an interrupt number check to prevent users from passing in an irq\nnumber that was too large.\n\nIf `it-\u0026gt;options[1]` is 31, then `1 \u0026lt;\u0026lt; it-\u0026gt;options[1]` is still invalid\nbecause it shifts a 1-bit into the sign bit (which is UB in C).\nPossible solutions include reducing the upper bound on the\n`it-\u0026gt;options[1]` value to 30 or lower, or using `1U \u0026lt;\u0026lt; it-\u0026gt;options[1]`.\n\nThe old code would just not attempt to request the IRQ if the\n`options[1]` value were invalid. And it would still configure the\ndevice without interrupts even if the call to `request_irq` returned an\nerror. So it would be better to combine this test with the test below.(CVE-2025-39685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: pfr_update: Fix the driver update version check\n\nThe security-version-number check should be used rather\nthan the runtime version check for driver updates.\n\nOtherwise, the firmware update would fail when the update binary had\na lower runtime version number than the current one.\n\n[ rjw: Changelog edits ](CVE-2025-39701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough. memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic. The race is as\nfollows:\n\ncpu0 cpu1\n shrink_folio_list memory_failure\n TestSetPageHWPoison\n unmap_poisoned_folio\n --\u0026gt; trigger BUG_ON due to\n unmap_poisoned_folio couldn\u0026apos;t\n handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()\n\nThe function divides number of online CPUs by num_core_siblings, and\nlater checks the divider by zero. This implies a possibility to get\nand divide-by-zero runtime error. Fix it by moving the check prior to\ndivision. This also helps to save one indentation level.(CVE-2025-39742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix lockdep assertion on sync reset unload event\n\nFix lockdep assertion triggered during sync reset unload event. When the\nsync reset flow is initiated using the devlink reload fw_activate\noption, the PF already holds the devlink lock while handling unload\nevent. In this case, delegate sync reset unload event handling back to\nthe devlink callback process to avoid double-locking and resolve the\nlockdep warning.\n\nKernel log:\nWARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40\n[...]\nCall Trace:\n\u0026lt;TASK\u0026gt;\n mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]\n mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]\n process_one_work+0x222/0x640\n worker_thread+0x199/0x350\n kthread+0x10b/0x230\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x8e/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2025-39832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix memory leak in pad_compress_skb\n\nIf alloc_skb() fails in pad_compress_skb(), it returns NULL without\nreleasing the old skb. The caller does:\n\n skb = pad_compress_skb(ppp, skb);\n if (!skb)\n goto drop;\n\ndrop:\n kfree_skb(skb);\n\nWhen pad_compress_skb() returns NULL, the reference to the old skb is\nlost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.\n\nAlign pad_compress_skb() semantics with realloc(): only free the old\nskb if allocation and compression succeed. At the call site, use the\nnew_skb variable so the original skb is not lost when pad_compress_skb()\nfails.(CVE-2025-39847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n CPU1 CPU2 (close())\n ---- ----\n sock_hold(sk) sock_hold(sk);\n lock_sock(sk) \u0026lt;-- block close()\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- refcnt by bt_accept_enqueue()\n release_sock(sk)\n lock_sock(sk)\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- last refcnt\n bt_accept_unlink(sk) \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix invalid accesses to ceph_connection_v1_info\n\nThere is a place where generic code in messenger.c is reading and\nanother place where it is writing to con-\u0026gt;v1 union member without\nchecking that the union member is active (i.e. msgr1 is in use).\n\nOn 64-bit systems, con-\u0026gt;v1.auth_retry overlaps with con-\u0026gt;v2.out_iter,\nso such a read is almost guaranteed to return a bogus value instead of\n0 when msgr2 is in use. This ends up being fairly benign because the\nside effect is just the invalidation of the authorizer and successive\nfetching of new tickets.\n\ncon-\u0026gt;v1.connect_seq overlaps with con-\u0026gt;v2.conn_bufs and the fact that\nit\u0026apos;s being written to can cause more serious consequences, but luckily\nit\u0026apos;s not something that happens often.(CVE-2025-39880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Check encryption key size on incoming connection\n\nThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case:\n Security Mode 4 Level 4, Responder - Invalid Encryption Key Size\n - 128 bit\n\nThis tests the security key with size from 1 to 15 bytes while the\nSecurity Mode 4 Level 4 requests 16 bytes key size.\n\nCurrently PTS fails with the following logs:\n- expected:Connection Response:\n Code: [3 (0x03)] Code\n Identifier: (lt)WildCard: Exists(gt)\n Length: [8 (0x0008)]\n Destination CID: (lt)WildCard: Exists(gt)\n Source CID: [64 (0x0040)]\n Result: [3 (0x0003)] Connection refused - Security block\n Status: (lt)WildCard: Exists(gt),\nbut received:Connection Response:\n Code: [3 (0x03)] Code\n Identifier: [1 (0x01)]\n Length: [8 (0x0008)]\n Destination CID: [64 (0x0040)]\n Source CID: [64 (0x0040)]\n Result: [0 (0x0000)] Connection Successful\n Status: [0 (0x0000)] No further information available\n\nAnd HCI logs:\n\u0026lt; HCI Command: Read Encrypti.. (0x05|0x0008) plen 2\n Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n\u0026gt; HCI Event: Command Complete (0x0e) plen 7\n Read Encryption Key Size (0x05|0x0008) ncmd 1\n Status: Success (0x00)\n Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n Key size: 7\n\u0026gt; ACL Data RX: Handle 14 flags 0x02 dlen 12\n L2CAP: Connection Request (0x02) ident 1 len 4\n PSM: 4097 (0x1001)\n Source CID: 64\n\u0026lt; ACL Data TX: Handle 14 flags 0x00 dlen 16\n L2CAP: Connection Response (0x03) ident 1 len 8\n Destination CID: 64\n Source CID: 64\n Result: Connection successful (0x0000)\n Status: No further information available (0x0000)(CVE-2025-39889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup) | CPU 1 (delayed work callback)\ncnic_netdev_event() |\n cnic_stop_hw() | cnic_delete_task()\n cnic_cm_stop_bnx2x_hw() | ...\n cancel_delayed_work() | /* the queue_delayed_work()\n flush_workqueue() | executes after flush_workqueue()*/\n | queue_delayed_work()\n cnic_free_dev(dev)//free | cnic_delete_task() //new instance\n | dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays \u2014 such as inserting calls to ssleep()\nwithin the cnic_delete_task() function \u2014 to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don\u0026apos;t collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc\u0026apos;ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere \u0026quot;ADDRESS\u0026quot; is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn-\u0026gt;cdev-\u0026gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware\u0026apos;s return value to the maximum\nnumber of legal elements the firmware should return.(CVE-2025-39949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix validation of VF state in get resources\n\nVF state I40E_VF_STATE_ACTIVE is not the only state in which\nVF is actually active so it should not be used to determine\nif a VF is allowed to obtain resources.\n\nUse I40E_VF_STATE_RESOURCES_LOADED that is set only in\ni40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix input validation logic for action_meta\n\nFix condition to check \u0026apos;greater or equal\u0026apos; to prevent OOB dereference.(CVE-2025-39970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix idx validation in i40e_validate_queue_map\n\nEnsure idx is within range of active/initialized TCs when iterating over\nvf-\u0026gt;ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Prevent use-after-free during requeue-PI\n\nsyzbot managed to trigger the following race:\n\n T1 T2\n\n futex_wait_requeue_pi()\n futex_do_wait()\n schedule()\n futex_requeue()\n futex_proxy_trylock_atomic()\n futex_requeue_pi_prepare()\n requeue_pi_wake_futex()\n futex_requeue_pi_complete()\n /* preempt */\n\n * timeout/ signal wakes T1 *\n\n futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED\n futex_hash_put()\n // back to userland, on stack futex_q is garbage\n\n /* back */\n wake_up_state(q-\u0026gt;task, TASK_NORMAL);\n\nIn this scenario futex_wait_requeue_pi() is able to leave without using\nfutex_q::lock_ptr for synchronization.\n\nThis can be prevented by reading futex_q::task before updating the\nfutex_q::requeue_state. A reference on the task_struct is not needed\nbecause requeue_pi_wake_futex() is invoked with a spinlock_t held which\nimplies a RCU read section.\n\nEven if T1 terminates immediately after, the task_struct will remain valid\nduring T2\u0026apos;s wake_up_state(). A READ_ONCE on futex_q::task before\nfutex_requeue_pi_complete() is enough because it ensures that the variable\nis read before the state is updated.\n\nRead futex_q::task before updating the requeue state, use it for the\nfollowing wakeup.(CVE-2025-39977)\n\nIn the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)",
"id": "OESA-2025-2635",
"modified": "2026-08-06T11:09:45Z",
"published": "2025-11-07T11:09:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39701"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39742"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39970"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39972"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39977"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
}
],
"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-2025-21991",
"CVE-2025-37998",
"CVE-2025-39685",
"CVE-2025-39701",
"CVE-2025-39725",
"CVE-2025-39742",
"CVE-2025-39782",
"CVE-2025-39832",
"CVE-2025-39847",
"CVE-2025-39860",
"CVE-2025-39880",
"CVE-2025-39889",
"CVE-2025-39945",
"CVE-2025-39949",
"CVE-2025-39969",
"CVE-2025-39970",
"CVE-2025-39972",
"CVE-2025-39973",
"CVE-2025-39977",
"CVE-2025-40006",
"CVE-2025-40021",
"CVE-2025-40042",
"CVE-2025-40057",
"CVE-2025-40071",
"CVE-2025-40081",
"CVE-2025-40102"
]
}
OESA-2025-2800 (CVE-2023-53091)
Vulnerability from osv_openeuler – Published: 2025-12-12 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix nexthop hash size
The nexthop code expects a 31 bit hash, such as what is returned by fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash returned by skb_get_hash() can lead to problems related to the fact that 'int hash' is a negative number when the MSB is set.
In the case of hash threshold nexthop groups, nexthop_select_path_hthr() will disproportionately select the first nexthop group entry. In the case of resilient nexthop groups, nexthop_select_path_res() may do an out of bounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535
which leads to the following panic:
BUG: unable to handle page fault for address: ffffc900025910c8 PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:nexthop_select_path+0x197/0xbf0 Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP: 0018:ffff88810c36f260 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfxlockacquire+0x10/0x10 ? pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfxdevqueue_xmit+0x10/0x10 ? pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfxlockacquire+0x10/0x10 ? pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60
---truncated---(CVE-2023-53192)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.(CVE-2023-53282)
In the Linux kernel, the following vulnerability has been resolved:
start_kernel: Add __no_stack_protector function attribute
Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it.
Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.(CVE-2023-53491)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.(CVE-2023-53520)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without hci_conn_get, so disconn_cfm must be called so they can clean up their conn, otherwise use-after-free occurs.
ISO:
iso_sock_connect:880: sk 00000000eabd6557 iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073 hci_dev_put:1487: hci0 orig refcnt 17 __iso_chan_add:214: conn 00000000b6251073 iso_sock_clear_timer:117: sock 00000000eabd6557 state 3 ... hci_rx_work:4085: hci0 Event packet hci_event_packet:7601: hci0: event 0x0f hci_cmd_status_evt:4346: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3107: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560 hci_conn_unlink:1102: hci0: hcon 000000001696f1fd hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2 hci_chan_list_flush:2780: hcon 000000001696f1fd hci_dev_put:1487: hci0 orig refcnt 21 hci_dev_put:1487: hci0 orig refcnt 20 hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c ... <no iso_* activity on sk/conn> ... iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557 BUG: kernel NULL pointer dereference, address: 0000000000000668 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth ==========================================================
L2CAP:
hci_cmd_status_evt:4359: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3085: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585 hci_conn_unlink:1102: hci0: hcon ffff88800c999000 hci_chan_list_flush:2780: hcon ffff88800c999000 hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280 ... BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth] Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfxlockacquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfxlockacquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7ff45cb23e64 Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: ---truncated---(CVE-2023-53673)
In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)
In the Linux kernel, the following vulnerability has been resolved:Revert mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits. This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways. Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - thedefault settings with 4GB of RAM will trigger this). Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs. We havediv64_ul() in case we want to be safe & cheap. Thirdly, if dirtythresholds are larger than 1<<32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)
In the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[ 161.115610] ------------[ cut here ]------------[ 161.116465] nfsd: non-standard errno: -74[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[ 161.118596] Modules linked in:[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 161.141519] PKRU: 55555554[ 161.142076] Call Trace:[ 161.142575] ? __warn+0x9b/0x140[ 161.143229] ? nfserrno+0x9d/0xd0[ 161.143872] ? report_bug+0x125/0x150[ 161.144595] ? handle_bug+0x41/0x90[ 161.145284] ? exc_invalid_op+0x14/0x70[ 161.146009] ? asm_exc_invalid_op+0x12/0x20[ 161.146816] ? nfserrno+0x9d/0xd0[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170[ 161.151004] ? generic_file_llseek_size+0x48/0x160[ 161.151895] nfsd_readdir+0x132/0x190[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.153516] ? nfsd_unlink+0x380/0x380[ 161.154256] ? override_creds+0x45/0x60[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0[ 161.158494] ? lock_downgrade+0x90/0x90[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10[ 161.160092] nfsd4_encode_operation+0x15a/0x440[ 161.160959] nfsd4_proc_compound+0x718/0xe90[ 161.161818] nfsd_dispatch+0x18e/0x2c0[ 161.162586] svc_process_common+0x786/0xc50[ 161.163403] ? nfsd_svc+0x380/0x380[ 161.164137] ? svc_printk+0x160/0x160[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380[ 161.165808] ? nfsd_svc+0x380/0x380[ 161.166523] ? rcu_is_watching+0x23/0x40[ 161.167309] svc_process+0x1a5/0x200[ 161.168019] nfsd+0x1f5/0x380[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260[ 161.169554] kthread+0x1c4/0x210[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80[ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: rockchip_saradc: fix information leak in triggered buffer
The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20
Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---(CVE-2025-22022)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.(CVE-2025-22039)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang:
- Use-after-free when no tpgs are found:
This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do:
vhost_vq_set_backend(vq, vs_tpg); ...
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via:
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If a scsi request is then sent we do:
vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend
which sees the vs_tpg we just did a kfree on.
- Tpg dir removal hang:
This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.
The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg.
Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.
- Tpg leak:
This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names.
The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs.
Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.(CVE-2025-22083)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { / is more than half of this entry in 2nd half of the block? / if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfxdquotinitialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _bpfget_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 _bpfget_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 __bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47
Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifs_oplock_break
A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting:
cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Prevent access to vCPU events before init
Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.
In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection:
kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.(CVE-2025-40102)
In the Linux kernel, the following vulnerability has been resolved:
smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().
smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname().
Note that the returned value of smc_clc_prfx_set() is not used in the caller.
While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.(CVE-2025-40139)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"perf-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"perf-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-294.0.0.196.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: update s_journal_inum if it changes after journal replay\n\nWhen mounting a crafted ext4 image, s_journal_inum may change after journal\nreplay, which is obviously unreasonable because we have successfully loaded\nand replayed the journal through the old s_journal_inum. And the new\ns_journal_inum bypasses some of the checks in ext4_get_journal(), which\nmay trigger a null pointer dereference problem. So if s_journal_inum\nchanges after the journal replay, we ignore the change, and rewrite the\ncurrent journal_inum to the superblock.(CVE-2023-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix nexthop hash size\n\nThe nexthop code expects a 31 bit hash, such as what is returned by\nfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash\nreturned by skb_get_hash() can lead to problems related to the fact that\n\u0026apos;int hash\u0026apos; is a negative number when the MSB is set.\n\nIn the case of hash threshold nexthop groups, nexthop_select_path_hthr()\nwill disproportionately select the first nexthop group entry. In the case\nof resilient nexthop groups, nexthop_select_path_res() may do an out of\nbounds access in nh_buckets[], for example:\n hash = -912054133\n num_nh_buckets = 2\n bucket_index = 65535\n\nwhich leads to the following panic:\n\nBUG: unable to handle page fault for address: ffffc900025910c8\nPGD 100000067 P4D 100000067 PUD 10026b067 PMD 0\nOops: 0002 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nWorkqueue: ipv6_addrconf addrconf_dad_work\nRIP: 0010:nexthop_select_path+0x197/0xbf0\nCode: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff \u0026lt;4d\u0026gt; 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85\nRSP: 0018:ffff88810c36f260 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8\nRBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219\nR10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0\nR13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900\nFS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x1ee/0x5c0\n ? __pfx_is_prefetch.constprop.0+0x10/0x10\n ? __pfx_page_fault_oops+0x10/0x10\n ? search_bpf_extables+0xfe/0x1c0\n ? fixup_exception+0x3b/0x470\n ? exc_page_fault+0xf6/0x110\n ? asm_exc_page_fault+0x26/0x30\n ? nexthop_select_path+0x197/0xbf0\n ? nexthop_select_path+0x197/0xbf0\n ? lock_is_held_type+0xe7/0x140\n vxlan_xmit+0x5b2/0x2340\n ? __lock_acquire+0x92b/0x3370\n ? __pfx_vxlan_xmit+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_register_lock_class+0x10/0x10\n ? skb_network_protocol+0xce/0x2d0\n ? dev_hard_start_xmit+0xca/0x350\n ? __pfx_vxlan_xmit+0x10/0x10\n dev_hard_start_xmit+0xca/0x350\n __dev_queue_xmit+0x513/0x1e20\n ? __pfx___dev_queue_xmit+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? mark_held_locks+0x44/0x90\n ? skb_push+0x4c/0x80\n ? eth_header+0x81/0xe0\n ? __pfx_eth_header+0x10/0x10\n ? neigh_resolve_output+0x215/0x310\n ? ip6_finish_output2+0x2ba/0xc90\n ip6_finish_output2+0x2ba/0xc90\n ? lock_release+0x236/0x3e0\n ? ip6_mtu+0xbb/0x240\n ? __pfx_ip6_finish_output2+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? lock_is_held_type+0xe7/0x140\n ip6_finish_output+0x1ee/0x780\n ip6_output+0x138/0x460\n ? __pfx_ip6_output+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_ip6_finish_output+0x10/0x10\n NF_HOOK.constprop.0+0xc0/0x420\n ? __pfx_NF_HOOK.constprop.0+0x10/0x10\n ? ndisc_send_skb+0x2c0/0x960\n ? __pfx_lock_release+0x10/0x10\n ? __local_bh_enable_ip+0x93/0x110\n ? lock_is_held_type+0xe7/0x140\n ndisc_send_skb+0x4be/0x960\n ? __pfx_ndisc_send_skb+0x10/0x10\n ? mark_held_locks+0x65/0x90\n ? find_held_lock+0x83/0xa0\n ndisc_send_ns+0xb0/0x110\n ? __pfx_ndisc_send_ns+0x10/0x10\n addrconf_dad_work+0x631/0x8e0\n ? lock_acquire+0x180/0x3f0\n ? __pfx_addrconf_dad_work+0x10/0x10\n ? mark_held_locks+0x24/0x90\n process_one_work+0x582/0x9c0\n ? __pfx_process_one_work+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n ? mark_held_locks+0x24/0x90\n worker_thread+0x93/0x630\n ? __kthread_parkme+0xdc/0x100\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x1a5/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n \n---truncated---(CVE-2023-53192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write\n\nDuring the sysfs firmware write process, a use-after-free read warning is\nlogged from the lpfc_wr_object() routine:\n\n BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]\n Use-after-free read at 0x0000000000cf164d (in kfence-#111):\n lpfc_wr_object+0x235/0x310 [lpfc]\n lpfc_write_firmware.cold+0x206/0x30d [lpfc]\n lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]\n lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]\n kernfs_fop_write_iter+0x121/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1ef/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x59/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe driver accessed wr_object pointer data, which was initialized into\nmailbox payload memory, after the mailbox object was released back to the\nmailbox pool.\n\nFix by moving the mailbox free calls to the end of the routine ensuring\nthat we don\u0026apos;t reference internal mailbox memory after release.(CVE-2023-53282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstart_kernel: Add __no_stack_protector function attribute\n\nBack during the discussion of\ncommit a9a3ed1eff36 (\u0026quot;x86: Fix early boot crash on gcc-10, third try\u0026quot;)\nwe discussed the need for a function attribute to control the omission\nof stack protectors on a per-function basis; at the time Clang had\nsupport for no_stack_protector but GCC did not. This was fixed in\ngcc-11. Now that the function attribute is available, let\u0026apos;s start using\nit.\n\nCallers of boot_init_stack_canary need to use this function attribute\nunless they\u0026apos;re compiled with -fno-stack-protector, otherwise the canary\nstored in the stack slot of the caller will differ upon the call to\nboot_init_stack_canary. This will lead to a call to __stack_chk_fail()\nthen panic.(CVE-2023-53491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere\u0026apos;s the call trace:\n \u0026lt;4\u0026gt;[102152.653246] Call Trace:\n \u0026lt;4\u0026gt;[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]\n \u0026lt;4\u0026gt;[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]\n \u0026lt;4\u0026gt;[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]\n \u0026lt;4\u0026gt;[102152.653268] notifier_call_chain+0x43/0x6b\n \u0026lt;4\u0026gt;[102152.653271] __blocking_notifier_call_chain+0x48/0x69\n \u0026lt;4\u0026gt;[102152.653273] __pm_notifier_call_chain+0x22/0x39\n \u0026lt;4\u0026gt;[102152.653276] pm_suspend+0x287/0x57c\n \u0026lt;4\u0026gt;[102152.653278] state_store+0xae/0xe5\n \u0026lt;4\u0026gt;[102152.653281] kernfs_fop_write+0x109/0x173\n \u0026lt;4\u0026gt;[102152.653284] __vfs_write+0x16f/0x1a2\n \u0026lt;4\u0026gt;[102152.653287] ? selinux_file_permission+0xca/0x16f\n \u0026lt;4\u0026gt;[102152.653289] ? security_file_permission+0x36/0x109\n \u0026lt;4\u0026gt;[102152.653291] vfs_write+0x114/0x21d\n \u0026lt;4\u0026gt;[102152.653293] __x64_sys_write+0x7b/0xdb\n \u0026lt;4\u0026gt;[102152.653296] do_syscall_64+0x59/0x194\n \u0026lt;4\u0026gt;[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.(CVE-2023-53520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: call disconnect callback before deleting conn\n\nIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.\n\nISO, L2CAP and SCO connections refer to the hci_conn without\nhci_conn_get, so disconn_cfm must be called so they can clean up their\nconn, otherwise use-after-free occurs.\n\nISO:\n==========================================================\niso_sock_connect:880: sk 00000000eabd6557\niso_connect_cis:356: 70:1a:b8:98:ff:a2 -\u0026gt; 28:3d:c2:4a:7e:da\n...\niso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073\nhci_dev_put:1487: hci0 orig refcnt 17\n__iso_chan_add:214: conn 00000000b6251073\niso_sock_clear_timer:117: sock 00000000eabd6557 state 3\n...\nhci_rx_work:4085: hci0 Event packet\nhci_event_packet:7601: hci0: event 0x0f\nhci_cmd_status_evt:4346: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3107: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560\nhci_conn_unlink:1102: hci0: hcon 000000001696f1fd\nhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2\nhci_chan_list_flush:2780: hcon 000000001696f1fd\nhci_dev_put:1487: hci0 orig refcnt 21\nhci_dev_put:1487: hci0 orig refcnt 20\nhci_req_cmd_complete:3978: opcode 0x0406 status 0x0c\n... \u0026lt;no iso_* activity on sk/conn\u0026gt; ...\niso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557\nBUG: kernel NULL pointer dereference, address: 0000000000000668\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nRIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth\n==========================================================\n\nL2CAP:\n==================================================================\nhci_cmd_status_evt:4359: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3085: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585\nhci_conn_unlink:1102: hci0: hcon ffff88800c999000\nhci_chan_list_flush:2780: hcon ffff88800c999000\nhci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280\n...\nBUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]\nRead of size 8 at addr ffff888018ddd298 by task bluetoothd/1175\n\nCPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0xf8/0x180\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n kasan_report+0xa8/0xe0\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n hci_send_acl+0x2d/0x540 [bluetooth]\n ? __pfx___lock_acquire+0x10/0x10\n l2cap_chan_send+0x1fd/0x1300 [bluetooth]\n ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]\n ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]\n ? lock_release+0x1d5/0x3c0\n ? mark_held_locks+0x1a/0x90\n l2cap_sock_sendmsg+0x100/0x170 [bluetooth]\n sock_write_iter+0x275/0x280\n ? __pfx_sock_write_iter+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n do_iter_readv_writev+0x176/0x220\n ? __pfx_do_iter_readv_writev+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? selinux_file_permission+0x13e/0x210\n do_iter_write+0xda/0x340\n vfs_writev+0x1b4/0x400\n ? __pfx_vfs_writev+0x10/0x10\n ? __seccomp_filter+0x112/0x750\n ? populate_seccomp_data+0x182/0x220\n ? __fget_light+0xdf/0x100\n ? do_writev+0x19d/0x210\n do_writev+0x19d/0x210\n ? __pfx_do_writev+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0x60/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n ? do_syscall_64+0x6c/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7ff45cb23e64\nCode: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\nRSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: \n---truncated---(CVE-2023-53673)\n\nIn the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)\n\nIn the Linux kernel, the following vulnerability has been resolved:Revert mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits. This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways. Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh \u0026gt;= 1\u0026lt;\u0026lt;32 (which is actually common - thedefault settings with 4GB of RAM will trigger this). Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs. We havediv64_ul() in case we want to be safe \u0026amp; cheap. Thirdly, if dirtythresholds are larger than 1\u0026lt;\u0026lt;32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)\n\nIn the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[ 161.115610] ------------[ cut here ]------------[ 161.116465] nfsd: non-standard errno: -74[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[ 161.118596] Modules linked in:[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 161.141519] PKRU: 55555554[ 161.142076] Call Trace:[ 161.142575] ? __warn+0x9b/0x140[ 161.143229] ? nfserrno+0x9d/0xd0[ 161.143872] ? report_bug+0x125/0x150[ 161.144595] ? handle_bug+0x41/0x90[ 161.145284] ? exc_invalid_op+0x14/0x70[ 161.146009] ? asm_exc_invalid_op+0x12/0x20[ 161.146816] ? nfserrno+0x9d/0xd0[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170[ 161.151004] ? generic_file_llseek_size+0x48/0x160[ 161.151895] nfsd_readdir+0x132/0x190[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.153516] ? nfsd_unlink+0x380/0x380[ 161.154256] ? override_creds+0x45/0x60[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0[ 161.158494] ? lock_downgrade+0x90/0x90[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10[ 161.160092] nfsd4_encode_operation+0x15a/0x440[ 161.160959] nfsd4_proc_compound+0x718/0xe90[ 161.161818] nfsd_dispatch+0x18e/0x2c0[ 161.162586] svc_process_common+0x786/0xc50[ 161.163403] ? nfsd_svc+0x380/0x380[ 161.164137] ? svc_printk+0x160/0x160[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380[ 161.165808] ? nfsd_svc+0x380/0x380[ 161.166523] ? rcu_is_watching+0x23/0x40[ 161.167309] svc_process+0x1a5/0x200[ 161.168019] nfsd+0x1f5/0x380[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260[ 161.169554] kthread+0x1c4/0x210[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80[ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: rockchip_saradc: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; array is allocated via kmalloc() and it is used to push data\nto user space from a triggered buffer, but it does not set values for\ninactive channels, as it only uses iio_for_each_active_channel()\nto assign new values.\n\nUse kzalloc for the memory allocation to avoid pushing uninitialized\ninformation to userspace.(CVE-2024-57911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---(CVE-2025-22020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -\u0026gt; vhost_scsi_get_req -\u0026gt; vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs-\u0026gt;vs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs-\u0026gt;vs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs-\u0026gt;vs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven\u0026apos;t seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don\u0026apos;t teardown the old target tpg mapping and just overwrite\nthe target name and the vs-\u0026gt;vs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2\u0026apos;s\nname and we will only match that target\u0026apos;s tpgs when we loop over the\nvs-\u0026gt;vs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it\u0026apos;s already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst.(CVE-2025-22083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix WARN() in get_bpf_raw_tp_regs\n\nsyzkaller reported an issue:\n\nWARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nModules linked in:\nCPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nRSP: 0018:ffffc90003636fa8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c\nRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005\nRBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003\nR10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004\nR13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900\nFS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]\n bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]\n __bpf_prog_run include/linux/filter.h:718 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]\n bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405\n __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47\n __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47\n __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35\n __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]\n mmap_read_trylock include/linux/mmap_lock.h:204 [inline]\n stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157\n __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483\n ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]\n bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]\n bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n\nTracepoint like trace_mmap_lock_acquire_returned may cause nested call\nas the corner case show above, which will be resolved with more general\nmethod in the future. As a result, WARN_ON_ONCE will be triggered. As\nAlexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes\u0026apos; dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent\u0026apos;s parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n tc qdisc add dev lo root handle 1: drr\n tc filter add dev lo parent 1: basic classid 1:1\n tc class add dev lo parent 1: classid 1:1 drr\n tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n tc qdisc add dev lo parent 2:1 handle 3: netem\n tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n tc class delete dev lo classid 1:1\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n cifs_oplock_break()\n _cifsFileInfo_put(cfile)\n cifsFileInfo_put_final()\n cifs_sb_deactive()\n [last ref, start releasing sb]\n kill_sb()\n kill_anon_super()\n generic_shutdown_super()\n evict_inodes()\n dispose_list()\n evict()\n destroy_inode()\n call_rcu(\u0026amp;inode-\u0026gt;i_rcu, i_callback)\n spin_lock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- OK\n [later] i_callback()\n cifs_free_inode()\n kmem_cache_free(cinode)\n spin_unlock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- UAF\n cifs_done_oplock_break(cinode) \u0026lt;- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0026apos;t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0026apos;ve been\nthrown away by the eventual reset of the vCPU\u0026apos;s state.(CVE-2025-40102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)",
"id": "OESA-2025-2800",
"modified": "2026-08-06T11:09:55Z",
"published": "2025-12-12T11:09:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40139"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-53091",
"CVE-2023-53192",
"CVE-2023-53282",
"CVE-2023-53491",
"CVE-2023-53520",
"CVE-2023-53673",
"CVE-2024-38662",
"CVE-2024-42102",
"CVE-2024-49875",
"CVE-2024-57907",
"CVE-2024-57911",
"CVE-2024-58034",
"CVE-2025-21905",
"CVE-2025-22020",
"CVE-2025-22022",
"CVE-2025-22039",
"CVE-2025-22083",
"CVE-2025-23150",
"CVE-2025-23158",
"CVE-2025-37749",
"CVE-2025-37785",
"CVE-2025-37789",
"CVE-2025-37927",
"CVE-2025-38201",
"CVE-2025-38285",
"CVE-2025-38350",
"CVE-2025-38527",
"CVE-2025-38617",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-38729",
"CVE-2025-39851",
"CVE-2025-40102",
"CVE-2025-40139"
]
}
OESA-2025-2801 (CVE-2023-53091)
Vulnerability from osv_openeuler – Published: 2025-12-12 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.(CVE-2023-53282)
In the Linux kernel, the following vulnerability has been resolved:
start_kernel: Add __no_stack_protector function attribute
Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it.
Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.(CVE-2023-53491)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.(CVE-2023-53520)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without hci_conn_get, so disconn_cfm must be called so they can clean up their conn, otherwise use-after-free occurs.
ISO:
iso_sock_connect:880: sk 00000000eabd6557 iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073 hci_dev_put:1487: hci0 orig refcnt 17 __iso_chan_add:214: conn 00000000b6251073 iso_sock_clear_timer:117: sock 00000000eabd6557 state 3 ... hci_rx_work:4085: hci0 Event packet hci_event_packet:7601: hci0: event 0x0f hci_cmd_status_evt:4346: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3107: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560 hci_conn_unlink:1102: hci0: hcon 000000001696f1fd hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2 hci_chan_list_flush:2780: hcon 000000001696f1fd hci_dev_put:1487: hci0 orig refcnt 21 hci_dev_put:1487: hci0 orig refcnt 20 hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c ... <no iso_* activity on sk/conn> ... iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557 BUG: kernel NULL pointer dereference, address: 0000000000000668 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth ==========================================================
L2CAP:
hci_cmd_status_evt:4359: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3085: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585 hci_conn_unlink:1102: hci0: hcon ffff88800c999000 hci_chan_list_flush:2780: hcon ffff88800c999000 hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280 ... BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth] Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfxlockacquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfxlockacquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7ff45cb23e64 Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: ---truncated---(CVE-2023-53673)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: rockchip_saradc: fix information leak in triggered buffer
The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20
Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---(CVE-2025-22022)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.(CVE-2025-22039)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang:
- Use-after-free when no tpgs are found:
This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do:
vhost_vq_set_backend(vq, vs_tpg); ...
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via:
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If a scsi request is then sent we do:
vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend
which sees the vs_tpg we just did a kfree on.
- Tpg dir removal hang:
This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.
The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg.
Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.
- Tpg leak:
This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names.
The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs.
Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.(CVE-2025-22083)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { / is more than half of this entry in 2nd half of the block? / if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfxdquotinitialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _bpfget_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 _bpfget_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 __bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47
Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifs_oplock_break
A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting:
cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Prevent access to vCPU events before init
Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.
In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection:
kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.(CVE-2025-40102)
In the Linux kernel, the following vulnerability has been resolved:
smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().
smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname().
Note that the returned value of smc_clc_prfx_set() is not used in the caller.
While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.(CVE-2025-40139)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"perf-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-294.0.0.197.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"perf-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-294.0.0.197.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: update s_journal_inum if it changes after journal replay\n\nWhen mounting a crafted ext4 image, s_journal_inum may change after journal\nreplay, which is obviously unreasonable because we have successfully loaded\nand replayed the journal through the old s_journal_inum. And the new\ns_journal_inum bypasses some of the checks in ext4_get_journal(), which\nmay trigger a null pointer dereference problem. So if s_journal_inum\nchanges after the journal replay, we ignore the change, and rewrite the\ncurrent journal_inum to the superblock.(CVE-2023-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write\n\nDuring the sysfs firmware write process, a use-after-free read warning is\nlogged from the lpfc_wr_object() routine:\n\n BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]\n Use-after-free read at 0x0000000000cf164d (in kfence-#111):\n lpfc_wr_object+0x235/0x310 [lpfc]\n lpfc_write_firmware.cold+0x206/0x30d [lpfc]\n lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]\n lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]\n kernfs_fop_write_iter+0x121/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1ef/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x59/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe driver accessed wr_object pointer data, which was initialized into\nmailbox payload memory, after the mailbox object was released back to the\nmailbox pool.\n\nFix by moving the mailbox free calls to the end of the routine ensuring\nthat we don\u0026apos;t reference internal mailbox memory after release.(CVE-2023-53282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstart_kernel: Add __no_stack_protector function attribute\n\nBack during the discussion of\ncommit a9a3ed1eff36 (\u0026quot;x86: Fix early boot crash on gcc-10, third try\u0026quot;)\nwe discussed the need for a function attribute to control the omission\nof stack protectors on a per-function basis; at the time Clang had\nsupport for no_stack_protector but GCC did not. This was fixed in\ngcc-11. Now that the function attribute is available, let\u0026apos;s start using\nit.\n\nCallers of boot_init_stack_canary need to use this function attribute\nunless they\u0026apos;re compiled with -fno-stack-protector, otherwise the canary\nstored in the stack slot of the caller will differ upon the call to\nboot_init_stack_canary. This will lead to a call to __stack_chk_fail()\nthen panic.(CVE-2023-53491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere\u0026apos;s the call trace:\n \u0026lt;4\u0026gt;[102152.653246] Call Trace:\n \u0026lt;4\u0026gt;[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]\n \u0026lt;4\u0026gt;[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]\n \u0026lt;4\u0026gt;[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]\n \u0026lt;4\u0026gt;[102152.653268] notifier_call_chain+0x43/0x6b\n \u0026lt;4\u0026gt;[102152.653271] __blocking_notifier_call_chain+0x48/0x69\n \u0026lt;4\u0026gt;[102152.653273] __pm_notifier_call_chain+0x22/0x39\n \u0026lt;4\u0026gt;[102152.653276] pm_suspend+0x287/0x57c\n \u0026lt;4\u0026gt;[102152.653278] state_store+0xae/0xe5\n \u0026lt;4\u0026gt;[102152.653281] kernfs_fop_write+0x109/0x173\n \u0026lt;4\u0026gt;[102152.653284] __vfs_write+0x16f/0x1a2\n \u0026lt;4\u0026gt;[102152.653287] ? selinux_file_permission+0xca/0x16f\n \u0026lt;4\u0026gt;[102152.653289] ? security_file_permission+0x36/0x109\n \u0026lt;4\u0026gt;[102152.653291] vfs_write+0x114/0x21d\n \u0026lt;4\u0026gt;[102152.653293] __x64_sys_write+0x7b/0xdb\n \u0026lt;4\u0026gt;[102152.653296] do_syscall_64+0x59/0x194\n \u0026lt;4\u0026gt;[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.(CVE-2023-53520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: call disconnect callback before deleting conn\n\nIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.\n\nISO, L2CAP and SCO connections refer to the hci_conn without\nhci_conn_get, so disconn_cfm must be called so they can clean up their\nconn, otherwise use-after-free occurs.\n\nISO:\n==========================================================\niso_sock_connect:880: sk 00000000eabd6557\niso_connect_cis:356: 70:1a:b8:98:ff:a2 -\u0026gt; 28:3d:c2:4a:7e:da\n...\niso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073\nhci_dev_put:1487: hci0 orig refcnt 17\n__iso_chan_add:214: conn 00000000b6251073\niso_sock_clear_timer:117: sock 00000000eabd6557 state 3\n...\nhci_rx_work:4085: hci0 Event packet\nhci_event_packet:7601: hci0: event 0x0f\nhci_cmd_status_evt:4346: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3107: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560\nhci_conn_unlink:1102: hci0: hcon 000000001696f1fd\nhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2\nhci_chan_list_flush:2780: hcon 000000001696f1fd\nhci_dev_put:1487: hci0 orig refcnt 21\nhci_dev_put:1487: hci0 orig refcnt 20\nhci_req_cmd_complete:3978: opcode 0x0406 status 0x0c\n... \u0026lt;no iso_* activity on sk/conn\u0026gt; ...\niso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557\nBUG: kernel NULL pointer dereference, address: 0000000000000668\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nRIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth\n==========================================================\n\nL2CAP:\n==================================================================\nhci_cmd_status_evt:4359: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3085: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585\nhci_conn_unlink:1102: hci0: hcon ffff88800c999000\nhci_chan_list_flush:2780: hcon ffff88800c999000\nhci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280\n...\nBUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]\nRead of size 8 at addr ffff888018ddd298 by task bluetoothd/1175\n\nCPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0xf8/0x180\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n kasan_report+0xa8/0xe0\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n hci_send_acl+0x2d/0x540 [bluetooth]\n ? __pfx___lock_acquire+0x10/0x10\n l2cap_chan_send+0x1fd/0x1300 [bluetooth]\n ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]\n ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]\n ? lock_release+0x1d5/0x3c0\n ? mark_held_locks+0x1a/0x90\n l2cap_sock_sendmsg+0x100/0x170 [bluetooth]\n sock_write_iter+0x275/0x280\n ? __pfx_sock_write_iter+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n do_iter_readv_writev+0x176/0x220\n ? __pfx_do_iter_readv_writev+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? selinux_file_permission+0x13e/0x210\n do_iter_write+0xda/0x340\n vfs_writev+0x1b4/0x400\n ? __pfx_vfs_writev+0x10/0x10\n ? __seccomp_filter+0x112/0x750\n ? populate_seccomp_data+0x182/0x220\n ? __fget_light+0xdf/0x100\n ? do_writev+0x19d/0x210\n do_writev+0x19d/0x210\n ? __pfx_do_writev+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0x60/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n ? do_syscall_64+0x6c/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7ff45cb23e64\nCode: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\nRSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: \n---truncated---(CVE-2023-53673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: rockchip_saradc: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; array is allocated via kmalloc() and it is used to push data\nto user space from a triggered buffer, but it does not set values for\ninactive channels, as it only uses iio_for_each_active_channel()\nto assign new values.\n\nUse kzalloc for the memory allocation to avoid pushing uninitialized\ninformation to userspace.(CVE-2024-57911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---(CVE-2025-22020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -\u0026gt; vhost_scsi_get_req -\u0026gt; vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs-\u0026gt;vs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs-\u0026gt;vs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs-\u0026gt;vs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven\u0026apos;t seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don\u0026apos;t teardown the old target tpg mapping and just overwrite\nthe target name and the vs-\u0026gt;vs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2\u0026apos;s\nname and we will only match that target\u0026apos;s tpgs when we loop over the\nvs-\u0026gt;vs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it\u0026apos;s already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst.(CVE-2025-22083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix WARN() in get_bpf_raw_tp_regs\n\nsyzkaller reported an issue:\n\nWARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nModules linked in:\nCPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nRSP: 0018:ffffc90003636fa8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c\nRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005\nRBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003\nR10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004\nR13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900\nFS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]\n bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]\n __bpf_prog_run include/linux/filter.h:718 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]\n bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405\n __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47\n __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47\n __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35\n __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]\n mmap_read_trylock include/linux/mmap_lock.h:204 [inline]\n stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157\n __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483\n ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]\n bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]\n bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n\nTracepoint like trace_mmap_lock_acquire_returned may cause nested call\nas the corner case show above, which will be resolved with more general\nmethod in the future. As a result, WARN_ON_ONCE will be triggered. As\nAlexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes\u0026apos; dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent\u0026apos;s parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n tc qdisc add dev lo root handle 1: drr\n tc filter add dev lo parent 1: basic classid 1:1\n tc class add dev lo parent 1: classid 1:1 drr\n tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n tc qdisc add dev lo parent 2:1 handle 3: netem\n tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n tc class delete dev lo classid 1:1\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n cifs_oplock_break()\n _cifsFileInfo_put(cfile)\n cifsFileInfo_put_final()\n cifs_sb_deactive()\n [last ref, start releasing sb]\n kill_sb()\n kill_anon_super()\n generic_shutdown_super()\n evict_inodes()\n dispose_list()\n evict()\n destroy_inode()\n call_rcu(\u0026amp;inode-\u0026gt;i_rcu, i_callback)\n spin_lock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- OK\n [later] i_callback()\n cifs_free_inode()\n kmem_cache_free(cinode)\n spin_unlock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- UAF\n cifs_done_oplock_break(cinode) \u0026lt;- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0026apos;t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0026apos;ve been\nthrown away by the eventual reset of the vCPU\u0026apos;s state.(CVE-2025-40102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)",
"id": "OESA-2025-2801",
"modified": "2026-08-06T11:09:55Z",
"published": "2025-12-12T11:09:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40139"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-53091",
"CVE-2023-53282",
"CVE-2023-53491",
"CVE-2023-53520",
"CVE-2023-53673",
"CVE-2024-57907",
"CVE-2024-57911",
"CVE-2024-58034",
"CVE-2025-21905",
"CVE-2025-22020",
"CVE-2025-22022",
"CVE-2025-22039",
"CVE-2025-22083",
"CVE-2025-23150",
"CVE-2025-23158",
"CVE-2025-37749",
"CVE-2025-37785",
"CVE-2025-37789",
"CVE-2025-37927",
"CVE-2025-38201",
"CVE-2025-38285",
"CVE-2025-38350",
"CVE-2025-38527",
"CVE-2025-38617",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-38729",
"CVE-2025-39851",
"CVE-2025-40102",
"CVE-2025-40139"
]
}
OPENSUSE-SU-2025:15702-1
Vulnerability from csaf_opensuse - Published: 2025-11-04 00:00 - Updated: 2026-09-20 21:44OPENSUSE-SU-2025:20172-1
Vulnerability from csaf_opensuse - Published: 2025-12-19 17:38 - Updated: 2026-09-20 21:48Sightings
| 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.