Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-40902 (GCVE-0-2024-40902)
Vulnerability from cvelistv5 – Published: 2024-07-12 12:20 – Updated: 2026-08-05 11:33- CWE-121 - Stack-based Buffer Overflow
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < f0dedb5c511ed82cbaff4997a8decf2351ba549f
(git)
Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 1e84c9b1838152a87cf453270a5fa75c5037e83a (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < fc745f6e83cb650f9a5f2c864158e3a5ea76dad0 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 480e5bc21f2c42d90c2c16045d64d824dcdd5ec7 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 33aecc5799c93d3ee02f853cb94e201f9731f123 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 4598233d9748fe4db4e13b9f473588aa25e87d69 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < b537cb2f4c4a1357479716a9c339c0bda03d873f (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 7c55b78818cfb732680c4a72ab270cc2d2ee3d0f (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.12
Unaffected: 0 , < 2.6.12 (semver) Unaffected: 4.19.317 , ≤ 4.19.* (semver) Unaffected: 5.4.279 , ≤ 5.4.* (semver) Unaffected: 5.10.221 , ≤ 5.10.* (semver) Unaffected: 5.15.162 , ≤ 5.15.* (semver) Unaffected: 6.1.95 , ≤ 6.1.* (semver) Unaffected: 6.6.35 , ≤ 6.6.* (semver) Unaffected: 6.9.6 , ≤ 6.9.* (semver) Unaffected: 6.10 , ≤ * (original_commit_for_fix) |
guessed | |
| linux | linux_kernel |
Affected:
1da177e4c3f4 , < f0dedb5c511e
(git)
Affected: 1da177e4c3f4 , < 1e84c9b18381 (git) Affected: 1da177e4c3f4 , < fc745f6e83cb (git) Affected: 1da177e4c3f4 , < 480e5bc21f2c (git) Affected: 1da177e4c3f4 , < 33aecc5799c9 (git) Affected: 1da177e4c3f4 , < 4598233d9748 (git) Affected: 1da177e4c3f4 , < b537cb2f4c4a (git) Affected: 1da177e4c3f4 , < 7c55b78818cf (git) cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T21:57:30.293Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "f0dedb5c511e",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "1e84c9b18381",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "fc745f6e83cb",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "480e5bc21f2c",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "33aecc5799c9",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "4598233d9748",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "b537cb2f4c4a",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "7c55b78818cf",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
}
]
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2024-40902",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-08-16T04:02:10.264268Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-121",
"description": "CWE-121 Stack-based Buffer Overflow",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2024-08-20T14:03:35.925Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/jfs/xattr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f0dedb5c511ed82cbaff4997a8decf2351ba549f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "1e84c9b1838152a87cf453270a5fa75c5037e83a",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "fc745f6e83cb650f9a5f2c864158e3a5ea76dad0",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "480e5bc21f2c42d90c2c16045d64d824dcdd5ec7",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "33aecc5799c93d3ee02f853cb94e201f9731f123",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "4598233d9748fe4db4e13b9f473588aa25e87d69",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "b537cb2f4c4a1357479716a9c339c0bda03d873f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "7c55b78818cfb732680c4a72ab270cc2d2ee3d0f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/jfs/xattr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.12"
},
{
"lessThan": "2.6.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.317",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.279",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.221",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.162",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.95",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.35",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.317",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.279",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.221",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.162",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.95",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.35",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9.6",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10",
"versionStartIncluding": "2.6.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: xattr: fix buffer overflow for invalid xattr\n\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\n\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - Triggering requires a locally attached/mounted crafted JFS image, and the OOB read is reached through ordinary local syscalls (getxattr/listxattr/stat) on files in that filesystem. No network or remote-peer data path exists into fs/jfs/xattr.c.\nAC:L - The attacker fully controls every input \u2014 the on-disk `di_ea.flag`, the 32-bit `di_ea.size`, and the 128 inline EA bytes \u2014 so setting `EALIST_SIZE(xattr) != ea_size` with a huge `ea_size` deterministically drives print_hex_dump past the buffer. No race, no memory-layout dependency, no non-default config (JFS xattr support is unconditional in fs/jfs).\nPR:L - Once the image is mounted, any unprivileged user can trigger it via getxattr/listxattr or merely a permission check through jfs_get_acl, and the only CAP_SYS_ADMIN check on the path (can_list) runs after ea_get returns. On desktop/kiosk deployments udisks2/polkit lets an unprivileged console user mount removable media containing the crafted JFS image.\nUI:N - The attacker mounts their own crafted image and then triggers the read themselves; no victim action is needed at any point. Auto-mount of removable media likewise requires no deliberate victim interaction.\nS:U - The out-of-bounds read stays within the kernel\u0027s own address space and security authority \u2014 no VM, IOMMU, or sandbox boundary is crossed.\nC:H - This is an unbounded slab out-of-bounds read (up to INT_MAX bytes from a 128-byte inline buffer) whose contents are hex-dumped verbatim to the kernel log, leaking adjacent heap objects, kernel pointers, and other tasks\u0027 data \u2014 far beyond a small bounded read.\nI:H - The attacker-sized dump writes tens of megabytes to gigabytes of hex output into the kernel log ring buffer, destroying all prior log and audit records; combined with the leaked heap pointers this undermines KASLR and the integrity of the system\u0027s forensic record.\nA:H - Reading hundreds of megabytes past the end of a slab object reliably walks into unmapped memory and oopses/panics the kernel, and even short of that the multi-gigabyte KERN_ERR flood renders the system unusable."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:33:54.564Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
}
],
"title": "jfs: xattr: fix buffer overflow for invalid xattr",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-40902",
"datePublished": "2024-07-12T12:20:43.508Z",
"dateReserved": "2024-07-12T12:17:45.579Z",
"dateUpdated": "2026-08-05T11:33:54.564Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-40902",
"date": "2026-09-20",
"epss": "0.0032",
"percentile": "0.25171"
},
"fkie_nvd": {
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AD25C2E5-C116-4160-BA6D-CE9B0D10AE3E",
"versionEndExcluding": "4.19.317",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F4E38E58-1B9F-4DF2-AD3D-A8BEAA2959D8",
"versionEndExcluding": "5.4.279",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "659E1520-6345-41AF-B893-A7C0647585A0",
"versionEndExcluding": "5.10.221",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "10A39ACC-3005-40E8-875C-98A372D1FFD5",
"versionEndExcluding": "5.15.162",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D435765D-2766-44F5-B319-F713A13E35CE",
"versionEndExcluding": "6.1.95",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6F019D15-84C0-416B-8C57-7F51B68992F0",
"versionEndExcluding": "6.6.35",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0ABBBA1D-F79D-4BDB-AA41-D1EDCC4A6975",
"versionEndExcluding": "6.9.6",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc1:*:*:*:*:*:*",
"matchCriteriaId": "2EBB4392-5FA6-4DA9-9772-8F9C750109FA",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*",
"matchCriteriaId": "331C2F14-12C7-45D5-893D-8C52EE38EA10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*",
"matchCriteriaId": "3173713D-909A-4DD3-9DD4-1E171EB057EE",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: xattr: fix buffer overflow for invalid xattr\n\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\n\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del b\u00fafer para xattr no v\u00e1lido Cuando un tama\u00f1o de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuraci\u00f3n. Pero cuando el tama\u00f1o de xattr es mayor que el tama\u00f1o esperado, imprimirlo puede provocar un acceso desde el final del b\u00fafer. Solucione todo esto restringiendo adecuadamente el tama\u00f1o del volcado hexadecimal de depuraci\u00f3n en el registro del kernel."
}
],
"id": "CVE-2024-40902",
"lastModified": "2024-11-21T09:31:49.273",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
},
"published": "2024-07-12T13:15:13.583",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-120"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-121"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
},
"microsoft_vex": {
"current_release_date": "2026-02-18T02:44:20.000Z",
"cve": "CVE-2024-40902",
"id": "msrc_CVE-2024-40902",
"initial_release_date": "2024-07-01T07:00:00.000Z",
"product_status:fixed": "5",
"product_status:known_affected": "5",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "jfs: xattr: fix buffer overflow for invalid xattr",
"url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-40902.json",
"version": "13"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/jfs/xattr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f0dedb5c511ed82cbaff4997a8decf2351ba549f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "1e84c9b1838152a87cf453270a5fa75c5037e83a",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "fc745f6e83cb650f9a5f2c864158e3a5ea76dad0",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "480e5bc21f2c42d90c2c16045d64d824dcdd5ec7",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "33aecc5799c93d3ee02f853cb94e201f9731f123",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "4598233d9748fe4db4e13b9f473588aa25e87d69",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "b537cb2f4c4a1357479716a9c339c0bda03d873f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "7c55b78818cfb732680c4a72ab270cc2d2ee3d0f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/jfs/xattr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.12"
},
{
"lessThan": "2.6.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.317",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.279",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.221",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.162",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.95",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.35",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "f0dedb5c511e",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "1e84c9b18381",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "fc745f6e83cb",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "480e5bc21f2c",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "33aecc5799c9",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "4598233d9748",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "b537cb2f4c4a",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "7c55b78818cf",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
}
]
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AD25C2E5-C116-4160-BA6D-CE9B0D10AE3E",
"versionEndExcluding": "4.19.317",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F4E38E58-1B9F-4DF2-AD3D-A8BEAA2959D8",
"versionEndExcluding": "5.4.279",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "659E1520-6345-41AF-B893-A7C0647585A0",
"versionEndExcluding": "5.10.221",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "10A39ACC-3005-40E8-875C-98A372D1FFD5",
"versionEndExcluding": "5.15.162",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D435765D-2766-44F5-B319-F713A13E35CE",
"versionEndExcluding": "6.1.95",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6F019D15-84C0-416B-8C57-7F51B68992F0",
"versionEndExcluding": "6.6.35",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0ABBBA1D-F79D-4BDB-AA41-D1EDCC4A6975",
"versionEndExcluding": "6.9.6",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc1:*:*:*:*:*:*",
"matchCriteriaId": "2EBB4392-5FA6-4DA9-9772-8F9C750109FA",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*",
"matchCriteriaId": "331C2F14-12C7-45D5-893D-8C52EE38EA10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*",
"matchCriteriaId": "3173713D-909A-4DD3-9DD4-1E171EB057EE",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: xattr: fix buffer overflow for invalid xattr\n\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\n\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del b\u00fafer para xattr no v\u00e1lido Cuando un tama\u00f1o de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuraci\u00f3n. Pero cuando el tama\u00f1o de xattr es mayor que el tama\u00f1o esperado, imprimirlo puede provocar un acceso desde el final del b\u00fafer. Solucione todo esto restringiendo adecuadamente el tama\u00f1o del volcado hexadecimal de depuraci\u00f3n en el registro del kernel."
}
],
"id": "CVE-2024-40902",
"lastModified": "2026-06-17T07:46:49.640",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-40902",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-08-16T04:02:10.264268Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-07-12T13:15:13.583",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-120"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-121"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2025-11-21T14:34:11+00:00",
"cve": "CVE-2024-40902",
"id": "CVE-2024-40902",
"initial_release_date": "2024-07-12T00:00:00+00:00",
"product_status:known_affected": "14",
"product_status:known_not_affected": "184",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: jfs: xattr: fix buffer overflow for invalid xattr",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-40902.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-19T02:28:10Z",
"cve": "CVE-2024-40902",
"id": "CVE-2024-40902",
"initial_release_date": "2024-07-16T02:35:07Z",
"product_status:known_affected": "295",
"product_status:known_not_affected": "153",
"product_status:recommended": "795",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2024-40902",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-40902.json",
"version": "93"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T21:57:30.293Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "f0dedb5c511e",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "1e84c9b18381",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "fc745f6e83cb",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "480e5bc21f2c",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "33aecc5799c9",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "4598233d9748",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "b537cb2f4c4a",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "7c55b78818cf",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
}
]
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2024-40902",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-08-16T04:02:10.264268Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-121",
"description": "CWE-121 Stack-based Buffer Overflow",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2024-08-20T14:03:31.208Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/jfs/xattr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f0dedb5c511ed82cbaff4997a8decf2351ba549f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "1e84c9b1838152a87cf453270a5fa75c5037e83a",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "fc745f6e83cb650f9a5f2c864158e3a5ea76dad0",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "480e5bc21f2c42d90c2c16045d64d824dcdd5ec7",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "33aecc5799c93d3ee02f853cb94e201f9731f123",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "4598233d9748fe4db4e13b9f473588aa25e87d69",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "b537cb2f4c4a1357479716a9c339c0bda03d873f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "7c55b78818cfb732680c4a72ab270cc2d2ee3d0f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/jfs/xattr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.12"
},
{
"lessThan": "2.6.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.317",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.279",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.221",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.162",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.95",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.35",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.317",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.279",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.221",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.162",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.95",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.35",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9.6",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10",
"versionStartIncluding": "2.6.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: xattr: fix buffer overflow for invalid xattr\n\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\n\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log."
}
],
"providerMetadata": {
"dateUpdated": "2026-01-05T10:36:49.134Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
}
],
"title": "jfs: xattr: fix buffer overflow for invalid xattr",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-40902",
"datePublished": "2024-07-12T12:20:43.508Z",
"dateReserved": "2024-07-12T12:17:45.579Z",
"dateUpdated": "2026-01-05T10:36:49.134Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
FKIE_CVE-2024-40902
Vulnerability from fkie_nvd - Published: 2024-07-12 13:15 - Updated: 2026-06-17 07:467.8 (High) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.10 | |
| linux | linux_kernel | 6.10 | |
| linux | linux_kernel | 6.10 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/jfs/xattr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f0dedb5c511ed82cbaff4997a8decf2351ba549f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "1e84c9b1838152a87cf453270a5fa75c5037e83a",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "fc745f6e83cb650f9a5f2c864158e3a5ea76dad0",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "480e5bc21f2c42d90c2c16045d64d824dcdd5ec7",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "33aecc5799c93d3ee02f853cb94e201f9731f123",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "4598233d9748fe4db4e13b9f473588aa25e87d69",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "b537cb2f4c4a1357479716a9c339c0bda03d873f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "7c55b78818cfb732680c4a72ab270cc2d2ee3d0f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/jfs/xattr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.12"
},
{
"lessThan": "2.6.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.317",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.279",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.221",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.162",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.95",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.35",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "f0dedb5c511e",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "1e84c9b18381",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "fc745f6e83cb",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "480e5bc21f2c",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "33aecc5799c9",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "4598233d9748",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "b537cb2f4c4a",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
},
{
"lessThan": "7c55b78818cf",
"status": "affected",
"version": "1da177e4c3f4",
"versionType": "git"
}
]
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AD25C2E5-C116-4160-BA6D-CE9B0D10AE3E",
"versionEndExcluding": "4.19.317",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F4E38E58-1B9F-4DF2-AD3D-A8BEAA2959D8",
"versionEndExcluding": "5.4.279",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "659E1520-6345-41AF-B893-A7C0647585A0",
"versionEndExcluding": "5.10.221",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "10A39ACC-3005-40E8-875C-98A372D1FFD5",
"versionEndExcluding": "5.15.162",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D435765D-2766-44F5-B319-F713A13E35CE",
"versionEndExcluding": "6.1.95",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6F019D15-84C0-416B-8C57-7F51B68992F0",
"versionEndExcluding": "6.6.35",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0ABBBA1D-F79D-4BDB-AA41-D1EDCC4A6975",
"versionEndExcluding": "6.9.6",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc1:*:*:*:*:*:*",
"matchCriteriaId": "2EBB4392-5FA6-4DA9-9772-8F9C750109FA",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*",
"matchCriteriaId": "331C2F14-12C7-45D5-893D-8C52EE38EA10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*",
"matchCriteriaId": "3173713D-909A-4DD3-9DD4-1E171EB057EE",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: xattr: fix buffer overflow for invalid xattr\n\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\n\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del b\u00fafer para xattr no v\u00e1lido Cuando un tama\u00f1o de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuraci\u00f3n. Pero cuando el tama\u00f1o de xattr es mayor que el tama\u00f1o esperado, imprimirlo puede provocar un acceso desde el final del b\u00fafer. Solucione todo esto restringiendo adecuadamente el tama\u00f1o del volcado hexadecimal de depuraci\u00f3n en el registro del kernel."
}
],
"id": "CVE-2024-40902",
"lastModified": "2026-06-17T07:46:49.640",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-40902",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-08-16T04:02:10.264268Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-07-12T13:15:13.583",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-120"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-121"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-RPHX-6VQR-23H3
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump in the kernel log.
{
"affected": [],
"aliases": [
"CVE-2024-40902"
],
"database_specific": {
"cwe_ids": [
"CWE-120",
"CWE-121"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:13Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: xattr: fix buffer overflow for invalid xattr\n\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\n\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.",
"id": "GHSA-rphx-6vqr-23h3",
"modified": "2025-11-04T00:30:52Z",
"published": "2024-07-12T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
ICSA-25-226-07
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00MSRC_CVE-2024-40902
Vulnerability from csaf_microsoft - Published: 2024-07-01 07:00 - Updated: 2026-02-18 02:44NCSC-2024-0339
Vulnerability from csaf_ncscnl - Published: 2024-08-13 18:23 - Updated: 2024-08-13 18:23OESA-2024-1963 (CVE-2021-47202)
Vulnerability from osv_openeuler – Published: 2024-08-09 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
thermal: Fix NULL pointer dereferences in of_thermal_ functions
of_parse_thermal_zones() parses the thermal-zones node and registers a thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it.
console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200
While at it, fix the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend().(CVE-2021-47202)
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.
WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)
The warning triggers as this: packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKET
Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)
In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)
In the Linux kernel, the following vulnerability has been resolved:
xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.
syzbot reported:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835 xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)
In the Linux kernel, the following vulnerability has been resolved:
netrom: Fix a memory leak in nr_heartbeat_expiry()
syzbot reported a memory leak in nr_create() 0.
Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sock_hold() to the nr_heartbeat_expiry() function, where a) a socket has a SOCK_DESTROY flag or b) a listening socket has a SOCK_DEAD flag.
But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor has already been closed and the nr_release() function has been called. So it makes no sense to hold the reference count because no one will call another nr_destroy_socket() and put it as in the case "b."
nr_connect nr_establish_data_link nr_start_heartbeat
nr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY);
nr_rx_frame
nr_process_rx_frame
switch (nr->state)
case NR_STATE_2
nr_state2_machine()
nr_disconnect()
nr_sk(sk)->state = NR_STATE_0
sock_set_flag(sk, SOCK_DEAD)
nr_heartbeat_expiry
switch (nr->state)
case NR_STATE_0
if (sock_flag(sk, SOCK_DESTROY) ||
(sk->sk_state == TCP_LISTEN
&& sock_flag(sk, SOCK_DEAD)))
sock_hold() // ( !!! )
nr_destroy_socket()
To fix the memory leak, let's call sock_hold() only for a listening socket.
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.
In the Linux kernel, the following vulnerability has been resolved:
xfs: add bounds checking to xlog_recover_process_data
There is a lack of verification of the space occupied by fixed members of xlog_op_header in the xlog_recover_process_data.
We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crc
Fix: Add a check to make sure there is sufficient space to access fixed members of xlog_op_header.(CVE-2024-41014)
In the Linux kernel, the following vulnerability has been resolved:
jfs: don't walk off the end of ealist
Add a check before visiting the members of ea to make sure each ea stays within the ealist.(CVE-2024-41017)
In the Linux kernel, the following vulnerability has been resolved:
filelock: Fix fcntl/close race recovery compat path
When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport...
Apply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)
In the Linux kernel, the following vulnerability has been resolved:
ppp: reject claimed-as-LCP but actually malformed packets
Since 'ppp_async_encode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
syzbot is reporting that calling hci_release_dev() from hci_error_reset() due to hci_dev_put() from hci_error_reset() can cause deadlock at destroy_workqueue(), for hci_error_reset() is called from hdev->req_workqueue which destroy_workqueue() needs to flush.
We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are queued into hdev->workqueue and hdev->{power_on,error_reset} which are queued into hdev->req_workqueue are no longer running by the moment
destroy_workqueue(hdev->workqueue);
destroy_workqueue(hdev->req_workqueue);
are called from hci_release_dev().
Call cancel_work_sync() on these work items from hci_unregister_dev() as soon as hdev->list is removed from hci_dev_list.(CVE-2024-41063)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: topology: Fix references to freed memory
Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
In 'cfg80211_wext_siwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)
In the Linux kernel, the following vulnerability has been resolved:
ila: block BH in ila_output()
As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled.
ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock().
We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures.
Fix the race by using local_bh_disable().(CVE-2024-41081)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference.(CVE-2024-41089)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-41095)
In the Linux kernel, the following vulnerability has been resolved:
usb: atm: cxacru: fix endpoint checking in cxacru_bind()
Syzbot is still reporting quite an old issue 1 that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb().
Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type.
Unfortunately, this patch has not been tested on real hardware.
1 Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix DIO failure due to insufficient transaction credits
The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents.
Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem.
To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written().
Heming Zhao said:
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
11 dio_complete at ffffffff8c2b9fa7
12 do_blockdev_direct_IO at ffffffff8c2bc09f
13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
14 generic_file_direct_write at ffffffff8c1dcf14
15 __generic_file_write_iter at ffffffff8c1dd07b
16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
17 aio_write at ffffffff8c2cc72e
18 kmem_cache_alloc at ffffffff8c248dde
19 do_io_submit at ffffffff8c2ccada
20 do_syscall_64 at ffffffff8c004984
21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba(CVE-2024-42077)
In the Linux kernel, the following vulnerability has been resolved:
iio: chemical: bme680: Fix overflows in compensate() functions
There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here 1 and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor").
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock.
This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock.
This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)
In the Linux kernel, the following vulnerability has been resolved:
gpio: davinci: Validate the obtained number of IRQs
Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe().
Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: Avoid explicit cpumask var allocation on stack
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.(CVE-2024-42094)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: emux: improve patch ioctl data validation
In load_data(), make the validation of and skipping over the main info block match that in load_guspatch().
In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did.(CVE-2024-42097)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: add missing check for inode numbers on directory entries
Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn().
As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case).
The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking.
Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages.
Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis.(CVE-2024-42104)
In the Linux kernel, the following vulnerability has been resolved:
inet_diag: Initialize pad field in struct inet_diag_req_v2
KMSAN reported uninit-value access in raw_lookup() 1. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw.
inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field.
Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future.
1 BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 _syssendmsg+0x7f0/0xb70 net/socket.c:2585 _sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 _syssendmsg+0x7f0/0xb70 net/socket.c:2585 _sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: Fix potential illegal address access in jffs2_free_inode
During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2_free_inode+0x24/0x48 [ 2430.665233] i_callback+0x24/0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] __do_softirq+0x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffs_inode_info structure. It was found that all variables in the jffs_inode_info structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2_i_init_once, while other members are initialized in the function jffs2_init_inode_info.
The function jffs2_init_inode_info is called after iget_locked, but in the iget_locked function, the destroy_inode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, iget_locked may enter the destroy_inode branch as described in the code.
Since the destroy_inode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2_i_init_once.(CVE-2024-42115)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip finding free audio for unknown engine_id
[WHY] ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio.
[HOW] Skip and return NULL.
This fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)
In the Linux kernel, the following vulnerability has been resolved:
IB/core: Implement a limit on UMAD receive List
The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow.
To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space.
Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full.(CVE-2024-42145)
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Correct check for empty list
Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL.
This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists.
Instead, use list_first_entry_or_null() which does return NULL if the list is empty.
Flagged by Smatch. Compile tested only.(CVE-2024-42224)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc
Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2408.2.0.0289.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2408.2.0.0289.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: Fix NULL pointer dereferences in of_thermal_ functions\r\n\r\nof_parse_thermal_zones() parses the thermal-zones node and registers a\nthermal_zone device for each subnode. However, if a thermal zone is\nconsuming a thermal sensor and that thermal sensor device hasn\u0026apos;t probed\nyet, an attempt to set trip_point_*_temp for that thermal zone device\ncan cause a NULL pointer dereference. Fix it.\r\n\r\n console:/sys/class/thermal/thermal_zone87 # echo 120000 \u0026gt; trip_point_0_temp\n ...\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020\n ...\n Call trace:\n of_thermal_set_trip_temp+0x40/0xc4\n trip_point_temp_store+0xc0/0x1dc\n dev_attr_store+0x38/0x88\n sysfs_kf_write+0x64/0xc0\n kernfs_fop_write_iter+0x108/0x1d0\n vfs_write+0x2f4/0x368\n ksys_write+0x7c/0xec\n __arm64_sys_write+0x20/0x30\n el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc\n do_el0_svc+0x28/0xa0\n el0_svc+0x14/0x24\n el0_sync_handler+0x88/0xec\n el0_sync+0x1c0/0x200\r\n\r\nWhile at it, fix the possible NULL pointer dereference in other\nfunctions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),\nof_thermal_get_trend().(CVE-2021-47202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: Dont Use skb-\u0026gt;sk in ipvlan_process_v{4,6}_outbound\r\n\r\nRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will\nhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.\r\n\r\nWARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70\nModules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper\nCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:sk_mc_loop+0x2d/0x70\nCode: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c\nRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212\nRAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001\nRDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000\nRBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00\nR10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000\nR13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000\nFS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n ? __warn (kernel/panic.c:693)\n ? sk_mc_loop (net/core/sock.c:760)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:239)\n ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? sk_mc_loop (net/core/sock.c:760)\n ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))\n ? nf_hook_slow (net/netfilter/core.c:626)\n ip6_finish_output (net/ipv6/ip6_output.c:222)\n ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)\n ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan\n ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan\n dev_hard_start_xmit (net/core/dev.c:3594)\n sch_direct_xmit (net/sched/sch_generic.c:343)\n __qdisc_run (net/sched/sch_generic.c:416)\n net_tx_action (net/core/dev.c:5286)\n handle_softirqs (kernel/softirq.c:555)\n __irq_exit_rcu (kernel/softirq.c:589)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)\r\n\r\nThe warning triggers as this:\npacket_sendmsg\n packet_snd //skb-\u0026gt;sk is packet sk\n __dev_queue_xmit\n __dev_xmit_skb //q-\u0026gt;enqueue is not NULL\n __qdisc_run\n sch_direct_xmit\n dev_hard_start_xmit\n ipvlan_start_xmit\n ipvlan_xmit_mode_l3 //l3 mode\n ipvlan_process_outbound //vepa flag\n ipvlan_process_v6_outbound\n ip6_local_out\n __ip6_finish_output\n ip6_finish_output2 //multicast packet\n sk_mc_loop //sk-\u0026gt;sk_family is AF_PACKET\r\n\r\nCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: xattr: fix buffer overflow for invalid xattr\r\n\r\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\r\n\r\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.(CVE-2024-40902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()\r\n\r\nip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.\r\n\r\nsyzbot reported:\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: wg-kex-wg1 wg_packet_handshake_send_worker\n RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64\nCode: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00\nRSP: 0018:ffffc90000117378 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7\nRDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98\nRBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000\nR10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]\n xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]\n xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541\n xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835\n xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]\n xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201\n xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]\n xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309\n ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256\n send6+0x611/0xd20 drivers/net/wireguard/socket.c:139\n wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178\n wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200\n wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40\n wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n process_scheduled_works kernel/workqueue.c:3312 [inline]\n worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n kthread+0x2c1/0x3a0 kernel/kthread.c:389\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix a memory leak in nr_heartbeat_expiry()\r\n\r\nsyzbot reported a memory leak in nr_create() [0].\r\n\r\nCommit 409db27e3a2e (\u0026quot;netrom: Fix use-after-free of a listening socket.\u0026quot;)\nadded sock_hold() to the nr_heartbeat_expiry() function, where\na) a socket has a SOCK_DESTROY flag or\nb) a listening socket has a SOCK_DEAD flag.\r\n\r\nBut in the case \u0026quot;a,\u0026quot; when the SOCK_DESTROY flag is set, the file descriptor\nhas already been closed and the nr_release() function has been called.\nSo it makes no sense to hold the reference count because no one will\ncall another nr_destroy_socket() and put it as in the case \u0026quot;b.\u0026quot;\r\n\r\nnr_connect\n nr_establish_data_link\n nr_start_heartbeat\r\n\r\nnr_release\n switch (nr-\u0026gt;state)\n case NR_STATE_3\n nr-\u0026gt;state = NR_STATE_2\n sock_set_flag(sk, SOCK_DESTROY);\r\n\r\n nr_rx_frame\n nr_process_rx_frame\n switch (nr-\u0026gt;state)\n case NR_STATE_2\n nr_state2_machine()\n nr_disconnect()\n nr_sk(sk)-\u0026gt;state = NR_STATE_0\n sock_set_flag(sk, SOCK_DEAD)\r\n\r\n nr_heartbeat_expiry\n switch (nr-\u0026gt;state)\n case NR_STATE_0\n if (sock_flag(sk, SOCK_DESTROY) ||\n (sk-\u0026gt;sk_state == TCP_LISTEN\n \u0026amp;\u0026amp; sock_flag(sk, SOCK_DEAD)))\n sock_hold() // ( !!! )\n nr_destroy_socket()\r\n\r\nTo fix the memory leak, let\u0026apos;s call sock_hold() only for a listening socket.\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller.\r\n\r\n[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16(CVE-2024-41006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfs: add bounds checking to xlog_recover_process_data\r\n\r\nThere is a lack of verification of the space occupied by fixed members\nof xlog_op_header in the xlog_recover_process_data.\r\n\r\nWe can create a crafted image to trigger an out of bounds read by\nfollowing these steps:\n 1) Mount an image of xfs, and do some file operations to leave records\n 2) Before umounting, copy the image for subsequent steps to simulate\n abnormal exit. Because umount will ensure that tail_blk and\n head_blk are the same, which will result in the inability to enter\n xlog_recover_process_data\n 3) Write a tool to parse and modify the copied image in step 2\n 4) Make the end of the xlog_op_header entries only 1 byte away from\n xlog_rec_header-\u0026gt;h_size\n 5) xlog_rec_header-\u0026gt;h_num_logops++\n 6) Modify xlog_rec_header-\u0026gt;h_crc\r\n\r\nFix:\nAdd a check to make sure there is sufficient space to access fixed members\nof xlog_op_header.(CVE-2024-41014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: don\u0026apos;t walk off the end of ealist\r\n\r\nAdd a check before visiting the members of ea to\nmake sure each ea stays within the ealist.(CVE-2024-41017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Fix fcntl/close race recovery compat path\r\n\r\nWhen I wrote commit 3cad1bc01041 (\u0026quot;filelock: Remove locks reliably when\nfcntl/close race is detected\u0026quot;), I missed that there are two copies of the\ncode I was patching: The normal version, and the version for 64-bit offsets\non 32-bit kernels.\nThanks to Greg KH for stumbling over this while doing the stable\nbackport...\r\n\r\nApply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppp: reject claimed-as-LCP but actually malformed packets\r\n\r\nSince \u0026apos;ppp_async_encode()\u0026apos; assumes valid LCP packets (with code\nfrom 1 to 7 inclusive), add \u0026apos;ppp_check_packet()\u0026apos; to ensure that\nLCP packet has an actual body beyond PPP_LCP header bytes, and\nreject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: hci_core: cancel all works upon hci_unregister_dev()\r\n\r\nsyzbot is reporting that calling hci_release_dev() from hci_error_reset()\ndue to hci_dev_put() from hci_error_reset() can cause deadlock at\ndestroy_workqueue(), for hci_error_reset() is called from\nhdev-\u0026gt;req_workqueue which destroy_workqueue() needs to flush.\r\n\r\nWe need to make sure that hdev-\u0026gt;{rx_work,cmd_work,tx_work} which are\nqueued into hdev-\u0026gt;workqueue and hdev-\u0026gt;{power_on,error_reset} which are\nqueued into hdev-\u0026gt;req_workqueue are no longer running by the moment\r\n\r\n destroy_workqueue(hdev-\u0026gt;workqueue);\n destroy_workqueue(hdev-\u0026gt;req_workqueue);\r\n\r\nare called from hci_release_dev().\r\n\r\nCall cancel_work_sync() on these work items from hci_unregister_dev()\nas soon as hdev-\u0026gt;list is removed from hci_dev_list.(CVE-2024-41063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: topology: Fix references to freed memory\r\n\r\nMost users after parsing a topology file, release memory used by it, so\nhaving pointer references directly into topology file contents is wrong.\nUse devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: wext: add extra SIOCSIWSCAN data check\r\n\r\nIn \u0026apos;cfg80211_wext_siwscan()\u0026apos;, add extra check whether number of\nchannels passed via \u0026apos;ioctl(sock, SIOCSIWSCAN, ...)\u0026apos; doesn\u0026apos;t exceed\nIW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nila: block BH in ila_output()\r\n\r\nAs explained in commit 1378817486d6 (\u0026quot;tipc: block BH\nbefore using dst_cache\u0026quot;), net/core/dst_cache.c\nhelpers need to be called with BH disabled.\r\n\r\nila_output() is called from lwtunnel_output()\npossibly from process context, and under rcu_read_lock().\r\n\r\nWe might be interrupted by a softirq, re-enter ila_output()\nand corrupt dst_cache data structures.\r\n\r\nFix the race by using local_bh_disable().(CVE-2024-41081)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes\r\n\r\nIn nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().\nAdd a check to avoid null pointer dereference.(CVE-2024-41089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes\r\n\r\nIn nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-41095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: atm: cxacru: fix endpoint checking in cxacru_bind()\r\n\r\nSyzbot is still reporting quite an old issue [1] that occurs due to\nincomplete checking of present usb endpoints. As such, wrong\nendpoints types may be used at urb sumbitting stage which in turn\ntriggers a warning in usb_submit_urb().\r\n\r\nFix the issue by verifying that required endpoint types are present\nfor both in and out endpoints, taking into account cmd endpoint type.\r\n\r\nUnfortunately, this patch has not been tested on real hardware.\r\n\r\n[1] Syzbot report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\nModules linked in:\nCPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\n...\nCall Trace:\n cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649\n cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760\n cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209\n usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055\n cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363\n usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:517 [inline]\n really_probe+0x23c/0xcd0 drivers/base/dd.c:595\n __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777\n __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894\n bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427\n __device_attach+0x228/0x4a0 drivers/base/dd.c:965\n bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487\n device_add+0xc2f/0x2180 drivers/base/core.c:3354\n usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix DIO failure due to insufficient transaction credits\r\n\r\nThe code in ocfs2_dio_end_io_write() estimates number of necessary\ntransaction credits using ocfs2_calc_extend_credits(). This however does\nnot take into account that the IO could be arbitrarily large and can\ncontain arbitrary number of extents.\r\n\r\nExtent tree manipulations do often extend the current transaction but not\nin all of the cases. For example if we have only single block extents in\nthe tree, ocfs2_mark_extent_written() will end up calling\nocfs2_replace_extent_rec() all the time and we will never extend the\ncurrent transaction and eventually exhaust all the transaction credits if\nthe IO contains many single block extents. Once that happens a\nWARN_ON(jbd2_handle_buffer_credits(handle) \u0026lt;= 0) is triggered in\njbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to\nthis error. This was actually triggered by one of our customers on a\nheavily fragmented OCFS2 filesystem.\r\n\r\nTo fix the issue make sure the transaction always has enough credits for\none extent insert before each call of ocfs2_mark_extent_written().\r\n\r\nHeming Zhao said:\r\n\r\n------\nPANIC: \u0026quot;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error\u0026quot;\r\n\r\nPID: xxx TASK: xxxx CPU: 5 COMMAND: \u0026quot;SubmitThread-CA\u0026quot;\n #0 machine_kexec at ffffffff8c069932\n #1 __crash_kexec at ffffffff8c1338fa\n #2 panic at ffffffff8c1d69b9\n #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]\n #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]\n #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]\n #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]\n #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]\n #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]\n #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]\n#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]\n#11 dio_complete at ffffffff8c2b9fa7\n#12 do_blockdev_direct_IO at ffffffff8c2bc09f\n#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]\n#14 generic_file_direct_write at ffffffff8c1dcf14\n#15 __generic_file_write_iter at ffffffff8c1dd07b\n#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]\n#17 aio_write at ffffffff8c2cc72e\n#18 kmem_cache_alloc at ffffffff8c248dde\n#19 do_io_submit at ffffffff8c2ccada\n#20 do_syscall_64 at ffffffff8c004984\n#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba(CVE-2024-42077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: chemical: bme680: Fix overflows in compensate() functions\r\n\r\nThere are cases in the compensate functions of the driver that\nthere could be overflows of variables due to bit shifting ops.\nThese implications were initially discussed here [1] and they\nwere mentioned in log message of Commit 1b3bd8592780 (\u0026quot;iio:\nchemical: Add support for Bosch BME680 sensor\u0026quot;).\r\n\r\n[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/(CVE-2024-42086)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER\r\n\r\nIn create_pinctrl(), pinctrl_maps_mutex is acquired before calling\nadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()\ncalls pinctrl_free(). However, pinctrl_free() attempts to acquire\npinctrl_maps_mutex, which is already held by create_pinctrl(), leading to\na potential deadlock.\r\n\r\nThis patch resolves the issue by releasing pinctrl_maps_mutex before\ncalling pinctrl_free(), preventing the deadlock.\r\n\r\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpio: davinci: Validate the obtained number of IRQs\r\n\r\nValue of pdata-\u0026gt;gpio_unbanked is taken from Device Tree. In case of broken\nDT due to any error this value can be any. Without this value validation\nthere can be out of chips-\u0026gt;irqs array boundaries access in\ndavinci_gpio_probe().\r\n\r\nValidate the obtained nirq value so that it won\u0026apos;t exceed the maximum\nnumber of IRQs per bank.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: Avoid explicit cpumask var allocation on stack\r\n\r\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\r\n\r\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\r\n\r\nUse *cpumask_var API(s) to address it.(CVE-2024-42094)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: emux: improve patch ioctl data validation\r\n\r\nIn load_data(), make the validation of and skipping over the main info\nblock match that in load_guspatch().\r\n\r\nIn load_guspatch(), add checking that the specified patch length matches\nthe actually supplied data, like load_data() already did.(CVE-2024-42097)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: add missing check for inode numbers on directory entries\r\n\r\nSyzbot reported that mounting and unmounting a specific pattern of\ncorrupted nilfs2 filesystem images causes a use-after-free of metadata\nfile inodes, which triggers a kernel bug in lru_add_fn().\r\n\r\nAs Jan Kara pointed out, this is because the link count of a metadata file\ngets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),\ntries to delete that inode (ifile inode in this case).\r\n\r\nThe inconsistency occurs because directories containing the inode numbers\nof these metadata files that should not be visible in the namespace are\nread without checking.\r\n\r\nFix this issue by treating the inode numbers of these internal files as\nerrors in the sanity check helper when reading directory folios/pages.\r\n\r\nAlso thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer\nanalysis.(CVE-2024-42104)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet_diag: Initialize pad field in struct inet_diag_req_v2\r\n\r\nKMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw\nsockets uses the pad field in struct inet_diag_req_v2 for the\nunderlying protocol. This field corresponds to the sdiag_raw_protocol\nfield in struct inet_diag_req_raw.\r\n\r\ninet_diag_get_exact_compat() converts inet_diag_req to\ninet_diag_req_v2, but leaves the pad field uninitialized. So the issue\noccurs when raw_lookup() accesses the sdiag_raw_protocol field.\r\n\r\nFix this by initializing the pad field in\ninet_diag_get_exact_compat(). Also, do the same fix in\ninet_diag_dump_compat() to avoid the similar issue in the future.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]\nBUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71\n raw_lookup net/ipv4/raw_diag.c:49 [inline]\n raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71\n raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99\n inet_diag_cmd_exact+0x7d9/0x980\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]\n inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x332/0x3d0 net/socket.c:745\n ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639\n __sys_sendmsg net/socket.c:2668 [inline]\n __do_sys_sendmsg net/socket.c:2677 [inline]\n __se_sys_sendmsg net/socket.c:2675 [inline]\n __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675\n x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was stored to memory at:\n raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71\n raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99\n inet_diag_cmd_exact+0x7d9/0x980\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]\n inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x332/0x3d0 net/socket.c:745\n ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639\n __sys_sendmsg net/socket.c:2668 [inline]\n __do_sys_sendmsg net/socket.c:2677 [inline]\n __se_sys_sendmsg net/socket.c:2675 [inline]\n __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675\n x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nLocal variable req.i created at:\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]\n inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\r\n\r\nCPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njffs2: Fix potential illegal address access in jffs2_free_inode\r\n\r\nDuring the stress testing of the jffs2 file system,the following\nabnormal printouts were found:\n[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948\n[ 2430.649622] Mem abort info:\n[ 2430.649829] ESR = 0x96000004\n[ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 2430.650564] SET = 0, FnV = 0\n[ 2430.650795] EA = 0, S1PTW = 0\n[ 2430.651032] FSC = 0x04: level 0 translation fault\n[ 2430.651446] Data abort info:\n[ 2430.651683] ISV = 0, ISS = 0x00000004\n[ 2430.652001] CM = 0, WnR = 0\n[ 2430.652558] [0069696969696948] address between user and kernel address ranges\n[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP\n[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33\n[ 2430.655008] Hardware name: linux,dummy-virt (DT)\n[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 2430.656142] pc : kfree+0x78/0x348\n[ 2430.656630] lr : jffs2_free_inode+0x24/0x48\n[ 2430.657051] sp : ffff800009eebd10\n[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000\n[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000\n[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14\n[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000\n[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000\n[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19\n[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14\n[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302\n[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342\n[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000\n[ 2430.664217] Call trace:\n[ 2430.664528] kfree+0x78/0x348\n[ 2430.664855] jffs2_free_inode+0x24/0x48\n[ 2430.665233] i_callback+0x24/0x50\n[ 2430.665528] rcu_do_batch+0x1ac/0x448\n[ 2430.665892] rcu_core+0x28c/0x3c8\n[ 2430.666151] rcu_core_si+0x18/0x28\n[ 2430.666473] __do_softirq+0x138/0x3cc\n[ 2430.666781] irq_exit+0xf0/0x110\n[ 2430.667065] handle_domain_irq+0x6c/0x98\n[ 2430.667447] gic_handle_irq+0xac/0xe8\n[ 2430.667739] call_on_irq_stack+0x28/0x54\nThe parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of\nthe jffs_inode_info structure. It was found that all variables in the jffs_inode_info\nstructure were 5a5a5a5a, except for the first member sem. It is suspected that these\nvariables are not initialized because they were set to 5a5a5a5a during memory testing,\nwhich is meant to detect uninitialized memory.The sem variable is initialized in the\nfunction jffs2_i_init_once, while other members are initialized in\nthe function jffs2_init_inode_info.\r\n\r\nThe function jffs2_init_inode_info is called after iget_locked,\nbut in the iget_locked function, the destroy_inode process is triggered,\nwhich releases the inode and consequently, the target member of the inode\nis not initialized.In concurrent high pressure scenarios, iget_locked\nmay enter the destroy_inode branch as described in the code.\r\n\r\nSince the destroy_inode functionality of jffs2 only releases the target,\nthe fix method is to set target to NULL in jffs2_i_init_once.(CVE-2024-42115)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip finding free audio for unknown engine_id\r\n\r\n[WHY]\nENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it\nalso means it is uninitialized and does not need free audio.\r\n\r\n[HOW]\nSkip and return NULL.\r\n\r\nThis fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/core: Implement a limit on UMAD receive List\r\n\r\nThe existing behavior of ib_umad, which maintains received MAD\npackets in an unbounded list, poses a risk of uncontrolled growth.\nAs user-space applications extract packets from this list, the rate\nof extraction may not match the rate of incoming packets, leading\nto potential list overflow.\r\n\r\nTo address this, we introduce a limit to the size of the list. After\nconsidering typical scenarios, such as OpenSM processing, which can\nhandle approximately 100k packets per second, and the 1-second retry\ntimeout for most packets, we set the list size limit to 200k. Packets\nreceived beyond this limit are dropped, assuming they are likely timed\nout by the time they are handled by user-space.\r\n\r\nNotably, packets queued on the receive list due to reasons like\ntimed-out sends are preserved even when the list is full.(CVE-2024-42145)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dsa: mv88e6xxx: Correct check for empty list\r\n\r\nSince commit a3c53be55c95 (\u0026quot;net: dsa: mv88e6xxx: Support multiple MDIO\nbusses\u0026quot;) mv88e6xxx_default_mdio_bus() has checked that the\nreturn value of list_first_entry() is non-NULL.\r\n\r\nThis appears to be intended to guard against the list chip-\u0026gt;mdios being\nempty. However, it is not the correct check as the implementation of\nlist_first_entry is not designed to return NULL for empty lists.\r\n\r\nInstead, use list_first_entry_or_null() which does return NULL if the\nlist is empty.\r\n\r\nFlagged by Smatch.\nCompile tested only.(CVE-2024-42224)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc\r\n\r\nInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.\nV2: To really improve the handling we would actually\n need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)",
"id": "OESA-2024-1963",
"modified": "2026-08-06T11:07:26Z",
"published": "2024-08-09T11:07:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41017"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41069"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41097"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42090"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42092"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42094"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42097"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42115"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42224"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42228"
}
],
"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-2021-47202",
"CVE-2024-33621",
"CVE-2024-40902",
"CVE-2024-40959",
"CVE-2024-41006",
"CVE-2024-41014",
"CVE-2024-41017",
"CVE-2024-41020",
"CVE-2024-41044",
"CVE-2024-41063",
"CVE-2024-41069",
"CVE-2024-41072",
"CVE-2024-41081",
"CVE-2024-41089",
"CVE-2024-41095",
"CVE-2024-41097",
"CVE-2024-42077",
"CVE-2024-42086",
"CVE-2024-42090",
"CVE-2024-42092",
"CVE-2024-42094",
"CVE-2024-42097",
"CVE-2024-42104",
"CVE-2024-42106",
"CVE-2024-42115",
"CVE-2024-42119",
"CVE-2024-42145",
"CVE-2024-42224",
"CVE-2024-42228"
]
}
OESA-2024-2028 (CVE-2024-33621)
Vulnerability from osv_openeuler – Published: 2024-08-23 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.
WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)
The warning triggers as this: packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKET
Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)
In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: benchmark: fix node id validation
While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to:
BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node.
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.(CVE-2024-38544)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: enable proper endpoint verification
Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.
Fix the issue by checking for the existence of all proper endpoints with their according types intact.
Sadly, this patch has not been tested on real hardware.
[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>(CVE-2024-38565)
In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.(CVE-2024-38597)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)
In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)
In the Linux kernel, the following vulnerability has been resolved:
iommu: Return right value in iommu_sva_bind_device()
iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer.
In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all.(CVE-2024-40945)
In the Linux kernel, the following vulnerability has been resolved:
tty: add the option to have a tty reject a new ldisc
... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on.
This avoids the
BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659
when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock.(CVE-2024-40966)
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: fix infinite loop when xmit fails
When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application.
Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever.
The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus.
The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one().
Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message.
mkl: use more imperative wording in patch description
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.(CVE-2024-42070)
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid overflows in dirty throttling logic
The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX.
This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayed_work() and ceph_monc_stop()
The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
if (str[0 - 1] == '\n') followed closely by an OOB write in the formstr[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)
In the Linux kernel, the following vulnerability has been resolved:
ext4: make sure the first directory block is not a hole
The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.
ext4_mknod
...
ext4_add_entry
// Read block 0
ext4_read_dirblock(dir, block, DIRENT)
bh = ext4_bread(NULL, inode, block, 0)
if (!bh && (type == INDEX || type == DIRENT_HTREE))
// The first directory block is a hole
// But type == DIRENT, so no error is reported.
After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash.
Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace.(CVE-2024-43839)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"perf-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-224.0.0.123.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"perf-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-224.0.0.123.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-224.0.0.123.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: Dont Use skb-\u0026gt;sk in ipvlan_process_v{4,6}_outbound\r\n\r\nRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will\nhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.\r\n\r\nWARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70\nModules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper\nCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:sk_mc_loop+0x2d/0x70\nCode: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c\nRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212\nRAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001\nRDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000\nRBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00\nR10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000\nR13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000\nFS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n ? __warn (kernel/panic.c:693)\n ? sk_mc_loop (net/core/sock.c:760)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:239)\n ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? sk_mc_loop (net/core/sock.c:760)\n ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))\n ? nf_hook_slow (net/netfilter/core.c:626)\n ip6_finish_output (net/ipv6/ip6_output.c:222)\n ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)\n ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan\n ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan\n dev_hard_start_xmit (net/core/dev.c:3594)\n sch_direct_xmit (net/sched/sch_generic.c:343)\n __qdisc_run (net/sched/sch_generic.c:416)\n net_tx_action (net/core/dev.c:5286)\n handle_softirqs (kernel/softirq.c:555)\n __irq_exit_rcu (kernel/softirq.c:589)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)\r\n\r\nThe warning triggers as this:\npacket_sendmsg\n packet_snd //skb-\u0026gt;sk is packet sk\n __dev_queue_xmit\n __dev_xmit_skb //q-\u0026gt;enqueue is not NULL\n __qdisc_run\n sch_direct_xmit\n dev_hard_start_xmit\n ipvlan_start_xmit\n ipvlan_xmit_mode_l3 //l3 mode\n ipvlan_process_outbound //vepa flag\n ipvlan_process_v6_outbound\n ip6_local_out\n __ip6_finish_output\n ip6_finish_output2 //multicast packet\n sk_mc_loop //sk-\u0026gt;sk_family is AF_PACKET\r\n\r\nCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-mapping: benchmark: fix node id validation\r\n\r\nWhile validating node ids in map_benchmark_ioctl(), node_possible() may\nbe provided with invalid argument outside of [0,MAX_NUMNODES-1] range\nleading to:\r\n\r\nBUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nRead of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971\nCPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:117)\nkasan_report (mm/kasan/report.c:603)\nkasan_check_range (mm/kasan/generic.c:189)\nvariable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]\narch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]\n_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]\nnode_state (include/linux/nodemask.h:423) [inline]\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nCompare node ids with sane bounds first. NUMA_NO_NODE is considered a\nspecial valid case meaning that benchmarking kthreads won\u0026apos;t be bound to a\ncpuset of a given node.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/rxe: Fix seg fault in rxe_comp_queue_pkt\r\n\r\nIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the\nresp_pkts queue and then a decision is made whether to run the completer\ntask inline or schedule it. Finally the skb is dereferenced to bump a \u0026apos;hw\u0026apos;\nperformance counter. This is wrong because if the completer task is\nalready running in a separate thread it may have already processed the skb\nand freed it which can cause a seg fault. This has been observed\ninfrequently in testing at high scale.\r\n\r\nThis patch fixes this by changing the order of enqueuing the packet until\nafter the counter is accessed.(CVE-2024-38544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ar5523: enable proper endpoint verification\r\n\r\nSyzkaller reports [1] hitting a warning about an endpoint in use\nnot having an expected type to it.\r\n\r\nFix the issue by checking for the existence of all proper\nendpoints with their according types intact.\r\n\r\nSadly, this patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\n------------[ cut here ]------------\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275\n ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]\n ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]\n ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655\n usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573\n hub_port_connect drivers/usb/core/hub.c:5353 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]\n port_event drivers/usb/core/hub.c:5653 [inline]\n hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n \u0026lt;/TASK\u0026gt;(CVE-2024-38565)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nErhard reports netpoll warnings from sungem:\r\n\r\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\r\n\r\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0026apos;t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0026apos;t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.(CVE-2024-38597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix mb_cache_entry\u0026apos;s e_refcnt leak in ext4_xattr_block_cache_find()\r\n\r\nSyzbot reports a warning as follows:\r\n\r\n============================================\nWARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290\nModules linked in:\nCPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7\nRIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375\n generic_shutdown_super+0x136/0x2d0 fs/super.c:641\n kill_block_super+0x44/0x90 fs/super.c:1675\n ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327\n[...]\n============================================\r\n\r\nThis is because when finding an entry in ext4_xattr_block_cache_find(), if\next4_sb_bread() returns -ENOMEM, the ce\u0026apos;s e_refcnt, which has already grown\nin the __entry_find(), won\u0026apos;t be put away, and eventually trigger the above\nissue in mb_cache_destroy() due to reference count leakage.\r\n\r\nSo call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\r\n\r\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 (\u0026quot;Revert \u0026quot;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\u0026quot;\u0026quot;)\r\n\r\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can\u0026apos;t issue\nfrom raid5d().\r\n\r\nCurrent implementation in raid5d() has a weird dependence:\r\n\r\n1) md_check_recovery() from raid5d() must hold \u0026apos;reconfig_mutex\u0026apos; to clear\n MD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\r\n\r\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold \u0026apos;reconfig_mutex\u0026apos;, and md_check_recovery() can\u0026apos;t update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n\u0026apos;reconfig_mutex\u0026apos; is released.\r\n\r\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when \u0026apos;reconfig_mutex\u0026apos;\nis released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: xattr: fix buffer overflow for invalid xattr\r\n\r\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\r\n\r\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.(CVE-2024-40902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: Return right value in iommu_sva_bind_device()\r\n\r\niommu_sva_bind_device() should return either a sva bond handle or an\nERR_PTR value in error cases. Existing drivers (idxd and uacce) only\ncheck the return value with IS_ERR(). This could potentially lead to\na kernel NULL pointer dereference issue if the function returns NULL\ninstead of an error pointer.\r\n\r\nIn reality, this doesn\u0026apos;t cause any problems because iommu_sva_bind_device()\nonly returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.\nIn this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will\nreturn an error, and the device drivers won\u0026apos;t call iommu_sva_bind_device()\nat all.(CVE-2024-40945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: add the option to have a tty reject a new ldisc\r\n\r\n... and use it to limit the virtual terminals to just N_TTY. They are\nkind of special, and in particular, the \u0026quot;con_write()\u0026quot; routine violates\nthe \u0026quot;writes cannot sleep\u0026quot; rule that some ldiscs rely on.\r\n\r\nThis avoids the\r\n\r\n BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659\r\n\r\nwhen N_GSM has been attached to a virtual console, and gsmld_write()\ncalls con_write() while holding a spinlock, and con_write() then tries\nto get the console lock.(CVE-2024-40966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251xfd: fix infinite loop when xmit fails\r\n\r\nWhen the mcp251xfd_start_xmit() function fails, the driver stops\nprocessing messages, and the interrupt routine does not return,\nrunning indefinitely even after killing the running application.\r\n\r\nError messages:\n[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16\n[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).\n... and repeat forever.\r\n\r\nThe issue can be triggered when multiple devices share the same SPI\ninterface. And there is concurrent access to the bus.\r\n\r\nThe problem occurs because tx_ring-\u0026gt;head increments even if\nmcp251xfd_start_xmit() fails. Consequently, the driver skips one TX\npackage while still expecting a response in\nmcp251xfd_handle_tefif_one().\r\n\r\nResolve the issue by starting a workqueue to write the tx obj\nsynchronously if err = -EBUSY. In case of another error, decrement\ntx_ring-\u0026gt;head, remove skb from the echo stack, and drop the message.\r\n\r\n[mkl: use more imperative wording in patch description](CVE-2024-41088)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\r\n\r\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.(CVE-2024-42070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: fix shared irq handling on driver remove\r\n\r\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.(CVE-2024-42127)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: avoid overflows in dirty throttling logic\r\n\r\nThe dirty throttling logic is interspersed with assumptions that dirty\nlimits in PAGE_SIZE units fit into 32-bit (so that various multiplications\nfit into 64-bits). If limits end up being larger, we will hit overflows,\npossible divisions by 0 etc. Fix these problems by never allowing so\nlarge dirty limits as they have dubious practical value anyway. For\ndirty_bytes / dirty_background_bytes interfaces we can just refuse to set\nso large limits. For dirty_ratio / dirty_background_ratio it isn\u0026apos;t so\nsimple as the dirty limit is computed from the amount of available memory\nwhich can change due to memory hotplug etc. So when converting dirty\nlimits from ratios to numbers of pages, we just don\u0026apos;t allow the result to\nexceed UINT_MAX.\r\n\r\nThis is root-only triggerable problem which occurs when the operator\nsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibceph: fix race between delayed_work() and ceph_monc_stop()\r\n\r\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting(). Both of\nthese can requeue the delayed work which wouldn\u0026apos;t be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn\u0026apos;t mess with the delayed work in order\nto avoid interfering with the hunting interval logic. This part was\nmissed in commit b5d91704f53e (\u0026quot;libceph: behave in mon_fault() if\ncur_mon \u0026lt; 0\u0026quot;) and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u0026gt;auth and monc-\u0026gt;monmap being\nparticularly susceptible to quickly being reused.\r\n\r\nTo fix this:\r\n\r\n- clear monc-\u0026gt;cur_mon and monc-\u0026gt;hunting as part of closing the session\n in ceph_monc_stop()\n- bail from delayed_work() if monc-\u0026gt;cur_mon is cleared, similar to how\n it\u0026apos;s done in mon_fault() and finish_hunting() (based on monc-\u0026gt;hunting)\n- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: configfs: Prevent OOB read/write in usb_string_copy()\r\n\r\nUserspace provided string \u0026apos;s\u0026apos; could trivially have the length zero. Left\nunchecked this will firstly result in an OOB read in the form\n`if (str[0 - 1] == \u0026apos;\\n\u0026apos;) followed closely by an OOB write in the form\n`str[0 - 1] = \u0026apos;\\0\u0026apos;`.\r\n\r\nThere is already a validating check to catch strings that are too long.\nLet\u0026apos;s supply an additional check for invalid strings that are too short.(CVE-2024-42236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: make sure the first directory block is not a hole\r\n\r\nThe syzbot constructs a directory that has no dirblock but is non-inline,\ni.e. the first directory block is a hole. And no errors are reported when\ncreating files in this directory in the following flow.\r\n\r\n ext4_mknod\n ...\n ext4_add_entry\n // Read block 0\n ext4_read_dirblock(dir, block, DIRENT)\n bh = ext4_bread(NULL, inode, block, 0)\n if (!bh \u0026amp;\u0026amp; (type == INDEX || type == DIRENT_HTREE))\n // The first directory block is a hole\n // But type == DIRENT, so no error is reported.\r\n\r\nAfter that, we get a directory block without \u0026apos;.\u0026apos; and \u0026apos;..\u0026apos; but with a valid\ndentry. This may cause some code that relies on dot or dotdot (such as\nmake_indexed_dir()) to crash.\r\n\r\nTherefore when ext4_read_dirblock() finds that the first directory block\nis a hole report that the filesystem is corrupted and return an error to\navoid loading corrupted data from disk causing something bad.(CVE-2024-42304)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes\r\n\r\nIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: adjust \u0026apos;name\u0026apos; buf size of bna_tcb and bna_ccb structures\r\n\r\nTo have enough space to write all possible sprintf() args. Currently\n\u0026apos;name\u0026apos; size is 16, but the first \u0026apos;%s\u0026apos; specifier may already need at\nleast 16 characters, since \u0026apos;bnad-\u0026gt;netdev-\u0026gt;name\u0026apos; is used there.\r\n\r\nFor \u0026apos;%d\u0026apos; specifiers, assume that they require:\n * 1 char for \u0026apos;tx_id + tx_info-\u0026gt;tcb[i]-\u0026gt;id\u0026apos; sum, BNAD_MAX_TXQ_PER_TX is 8\n * 2 chars for \u0026apos;rx_id + rx_info-\u0026gt;rx_ctrl[i].ccb-\u0026gt;id\u0026apos;, BNAD_MAX_RXP_PER_RX\n is 16\r\n\r\nAnd replace sprintf with snprintf.\r\n\r\nDetected using the static analysis tool - Svace.(CVE-2024-43839)",
"id": "OESA-2024-2028",
"modified": "2026-08-06T11:07:30Z",
"published": "2024-08-23T11:07:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34777"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42236"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43839"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-33621",
"CVE-2024-34777",
"CVE-2024-38544",
"CVE-2024-38565",
"CVE-2024-38597",
"CVE-2024-39276",
"CVE-2024-39476",
"CVE-2024-40902",
"CVE-2024-40945",
"CVE-2024-40966",
"CVE-2024-41088",
"CVE-2024-42070",
"CVE-2024-42127",
"CVE-2024-42131",
"CVE-2024-42232",
"CVE-2024-42236",
"CVE-2024-42304",
"CVE-2024-42310",
"CVE-2024-43839"
]
}
OESA-2024-2029 (CVE-2024-26586)
Vulnerability from osv_openeuler – Published: 2024-08-23 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix stack corruption
When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found.
One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage.
In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required.
Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register.
Add a test case to make sure the machine does not crash when this condition is hit.
[1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 _syssendmsg+0x164/0x260 _sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26586)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes.
Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)
In the Linux kernel, the following vulnerability has been resolved:
sched/membarrier: reduce the ability to hammer on sys_membarrier
On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.(CVE-2024-26602)
In the Linux kernel, the following vulnerability has been resolved:
tun: limit printing rate when illegal packet received by tun dev
vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected.
net_ratelimit mechanism can be used to limit the dumping rate.
PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f(CVE-2024-27013)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix vf may be used uninitialized in this function warning
To fix the regression introduced by commit 52424f974bc5, which causes servers hang in very hard to reproduce conditions with resets races. Using two sources for the information is the root cause. In this function before the fix bumping v didn't mean bumping vf pointer. But the code used this variables interchangeably, so stale vf could point to different/not intended vf.
Remove redundant "v" variable and iterate via single VF pointer across whole function instead to guarantee VF pointer validity.(CVE-2024-36020)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: add missing firmware sanity checks
Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.(CVE-2024-36880)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during initialization
The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash.
This patch fixes this by registering the devlink after hardware initialization.(CVE-2024-36900)
In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis.
Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else.
To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false.
[0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfxinetcheck_established+0x10/0x10 tcp_v4_connect+0x278/0x530 inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>(CVE-2024-36904)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip on writeback when it's not applicable
[WHY] dynamic memory safety error detector (KASAN) catches and generates error messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not support certain features which are not initialized.
[HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)
In the Linux kernel, the following vulnerability has been resolved:
nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().
syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:
ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP
NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers.
nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment()
- reset skb->network_header
- save the original skb->{mac_heaeder,mac_len} in a local variable
- pull the NSH header
- resets skb->mac_header
- set up skb->mac_len and skb->protocol for the inner protocol.
and does the following for the segmented skb
- set ntohs(ETH_P_NSH) to skb->protocol
- push the NSH header
- restore skb->mac_header
- set skb->mac_header + mac_len to skb->network_header
- restore skb->mac_len
There are two problems in 6-7 and 8-9.
(a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.
Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment().
(b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted.
However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot.
If this happens, even the restored skb->mac_header points to the middle of the outer header.
It seems nsh_gso_segment() has never worked with outer headers so far.
At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header.
To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly.
[0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---(CVE-2024-36933)
In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1].
[1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 _syssendmsg+0x312/0x410 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
value changed: 0xffffffff83d7feb0 -> 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".
To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()
If we fail to allocate propname buffer, we need to drop the reference count we just took. Because the pinctrl_dt_free_maps() includes the droping operation, here we call it directly.(CVE-2024-36959)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.(CVE-2024-38544)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: enable proper endpoint verification
Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.
Fix the issue by checking for the existence of all proper endpoints with their according types intact.
Sadly, this patch has not been tested on real hardware.
[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>(CVE-2024-38565)
In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.(CVE-2024-38597)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)
In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)
In the Linux kernel, the following vulnerability has been resolved:
tty: add the option to have a tty reject a new ldisc
... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on.
This avoids the
BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659
when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock.(CVE-2024-40966)
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: fix infinite loop when xmit fails
When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application.
Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever.
The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus.
The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one().
Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message.
mkl: use more imperative wording in patch description
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.(CVE-2024-42070)
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid overflows in dirty throttling logic
The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX.
This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayed_work() and ceph_monc_stop()
The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
if (str[0 - 1] == '\n') followed closely by an OOB write in the formstr[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)
In the Linux kernel, the following vulnerability has been resolved:
ext4: make sure the first directory block is not a hole
The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.
ext4_mknod
...
ext4_add_entry
// Read block 0
ext4_read_dirblock(dir, block, DIRENT)
bh = ext4_bread(NULL, inode, block, 0)
if (!bh && (type == INDEX || type == DIRENT_HTREE))
// The first directory block is a hole
// But type == DIRENT, so no error is reported.
After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash.
Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace.(CVE-2024-43839)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"perf-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-224.0.0.127.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"perf-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-224.0.0.127.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-224.0.0.127.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix stack corruption\r\n\r\nWhen tc filters are first added to a net device, the corresponding local\nport gets bound to an ACL group in the device. The group contains a list\nof ACLs. In turn, each ACL points to a different TCAM region where the\nfilters are stored. During forwarding, the ACLs are sequentially\nevaluated until a match is found.\r\n\r\nOne reason to place filters in different regions is when they are added\nwith decreasing priorities and in an alternating order so that two\nconsecutive filters can never fit in the same region because of their\nkey usage.\r\n\r\nIn Spectrum-2 and newer ASICs the firmware started to report that the\nmaximum number of ACLs in a group is more than 16, but the layout of the\nregister that configures ACL groups (PAGT) was not updated to account\nfor that. It is therefore possible to hit stack corruption [1] in the\nrare case where more than 16 ACLs in a group are required.\r\n\r\nFix by limiting the maximum ACL group size to the minimum between what\nthe firmware reports and the maximum ACLs that fit in the PAGT register.\r\n\r\nAdd a test case to make sure the machine does not crash when this\ncondition is hit.\r\n\r\n[1]\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120\n[...]\n dump_stack_lvl+0x36/0x50\n panic+0x305/0x330\n __stack_chk_fail+0x15/0x20\n mlxsw_sp_acl_tcam_group_update+0x116/0x120\n mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110\n mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20\n mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0\n mlxsw_sp_acl_rule_add+0x47/0x240\n mlxsw_sp_flower_replace+0x1a9/0x1d0\n tc_setup_cb_add+0xdc/0x1c0\n fl_hw_replace_filter+0x146/0x1f0\n fl_change+0xc17/0x1360\n tc_new_tfilter+0x472/0xb90\n rtnetlink_rcv_msg+0x313/0x3b0\n netlink_rcv_skb+0x58/0x100\n netlink_unicast+0x244/0x390\n netlink_sendmsg+0x1e4/0x440\n ____sys_sendmsg+0x164/0x260\n ___sys_sendmsg+0x9a/0xe0\n __sys_sendmsg+0x7a/0xc0\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache\r\n\r\nThere is a potential UAF scenario in the case of an LPI translation\ncache hit racing with an operation that invalidates the cache, such\nas a DISCARD ITS command. The root of the problem is that\nvgic_its_check_cache() does not elevate the refcount on the vgic_irq\nbefore dropping the lock that serializes refcount changes.\r\n\r\nHave vgic_its_check_cache() raise the refcount on the returned vgic_irq\nand add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/membarrier: reduce the ability to hammer on sys_membarrier\r\n\r\nOn some systems, sys_membarrier can be very expensive, causing overall\nslowdowns for everything. So put a lock on the path in order to\nserialize the accesses to prevent the ability for this to be called at\ntoo high of a frequency and saturate the machine.(CVE-2024-26602)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntun: limit printing rate when illegal packet received by tun dev\r\n\r\nvhost_worker will call tun call backs to receive packets. If too many\nillegal packets arrives, tun_do_read will keep dumping packet contents.\nWhen console is enabled, it will costs much more cpu time to dump\npacket and soft lockup will be detected.\r\n\r\nnet_ratelimit mechanism can be used to limit the dumping rate.\r\n\r\nPID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: \u0026quot;vhost-32980\u0026quot;\n #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253\n #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3\n #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e\n #3 [fffffe00003fced0] do_nmi at ffffffff8922660d\n #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663\n [exception RIP: io_serial_in+20]\n RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002\n RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000\n RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0\n RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f\n R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020\n R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000\n ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n #5 [ffffa655314979e8] io_serial_in at ffffffff89792594\n #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470\n #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6\n #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605\n #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558\n #10 [ffffa65531497ac8] console_unlock at ffffffff89316124\n #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07\n #12 [ffffa65531497b68] printk at ffffffff89318306\n #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765\n #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]\n #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]\n #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]\n #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]\n #18 [ffffa65531497f10] kthread at ffffffff892d2e72\n #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f(CVE-2024-27013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: fix vf may be used uninitialized in this function warning\r\n\r\nTo fix the regression introduced by commit 52424f974bc5, which causes\nservers hang in very hard to reproduce conditions with resets races.\nUsing two sources for the information is the root cause.\nIn this function before the fix bumping v didn\u0026apos;t mean bumping vf\npointer. But the code used this variables interchangeably, so stale vf\ncould point to different/not intended vf.\r\n\r\nRemove redundant \u0026quot;v\u0026quot; variable and iterate via single VF pointer across\nwhole function instead to guarantee VF pointer validity.(CVE-2024-36020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: qca: add missing firmware sanity checks\r\n\r\nAdd the missing sanity checks when parsing the firmware files before\ndownloading them to avoid accessing and corrupting memory beyond the\nvmalloced buffer.(CVE-2024-36880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix kernel crash when devlink reload during initialization\r\n\r\nThe devlink reload process will access the hardware resources,\nbut the register operation is done before the hardware is initialized.\nSo, processing the devlink reload during initialization may lead to kernel\ncrash.\r\n\r\nThis patch fixes this by registering the devlink after\nhardware initialization.(CVE-2024-36900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Use refcount_inc_not_zero() in tcp_twsk_unique().\r\n\r\nAnderson Nascimento reported a use-after-free splat in tcp_twsk_unique()\nwith nice analysis.\r\n\r\nSince commit ec94c2696f0b (\u0026quot;tcp/dccp: avoid one atomic operation for\ntimewait hashdance\u0026quot;), inet_twsk_hashdance() sets TIME-WAIT socket\u0026apos;s\nsk_refcnt after putting it into ehash and releasing the bucket lock.\r\n\r\nThus, there is a small race window where other threads could try to\nreuse the port during connect() and call sock_hold() in tcp_twsk_unique()\nfor the TIME-WAIT socket with zero refcnt.\r\n\r\nIf that happens, the refcnt taken by tcp_twsk_unique() is overwritten\nand sock_put() will cause underflow, triggering a real use-after-free\nsomewhere else.\r\n\r\nTo avoid the use-after-free, we need to use refcount_inc_not_zero() in\ntcp_twsk_unique() and give up on reusing the port if it returns false.\r\n\r\n[0]:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110\nCPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1\nHardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023\nRIP: 0010:refcount_warn_saturate+0xe5/0x110\nCode: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8\nRSP: 0018:ffffc90006b43b60 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027\nRDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0\nRBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0\nR10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84\nR13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0\nFS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xe5/0x110\n ? __warn+0x81/0x130\n ? refcount_warn_saturate+0xe5/0x110\n ? report_bug+0x171/0x1a0\n ? refcount_warn_saturate+0xe5/0x110\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? refcount_warn_saturate+0xe5/0x110\n tcp_twsk_unique+0x186/0x190\n __inet_check_established+0x176/0x2d0\n __inet_hash_connect+0x74/0x7d0\n ? __pfx___inet_check_established+0x10/0x10\n tcp_v4_connect+0x278/0x530\n __inet_stream_connect+0x10f/0x3d0\n inet_stream_connect+0x3a/0x60\n __sys_connect+0xa8/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0x83/0x170\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7f62c11a885d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d\nRDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003\nRBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0\nR13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0\n \u0026lt;/TASK\u0026gt;(CVE-2024-36904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip on writeback when it\u0026apos;s not applicable\r\n\r\n[WHY]\ndynamic memory safety error detector (KASAN) catches and generates error\nmessages \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot; as writeback connector does not\nsupport certain features which are not initialized.\r\n\r\n[HOW]\nSkip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnsh: Restore skb-\u0026gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().\r\n\r\nsyzbot triggered various splats (see [0] and links) by a crafted GSO\npacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:\r\n\r\n ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP\r\n\r\nNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner\nprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls\nskb_mac_gso_segment() to invoke inner protocol GSO handlers.\r\n\r\nnsh_gso_segment() does the following for the original skb before\ncalling skb_mac_gso_segment()\r\n\r\n 1. reset skb-\u0026gt;network_header\n 2. save the original skb-\u0026gt;{mac_heaeder,mac_len} in a local variable\n 3. pull the NSH header\n 4. resets skb-\u0026gt;mac_header\n 5. set up skb-\u0026gt;mac_len and skb-\u0026gt;protocol for the inner protocol.\r\n\r\nand does the following for the segmented skb\r\n\r\n 6. set ntohs(ETH_P_NSH) to skb-\u0026gt;protocol\n 7. push the NSH header\n 8. restore skb-\u0026gt;mac_header\n 9. set skb-\u0026gt;mac_header + mac_len to skb-\u0026gt;network_header\n 10. restore skb-\u0026gt;mac_len\r\n\r\nThere are two problems in 6-7 and 8-9.\r\n\r\n (a)\n After 6 \u0026amp; 7, skb-\u0026gt;data points to the NSH header, so the outer header\n (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.\r\n\r\n Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),\n skb_pull() in the first nsh_gso_segment() will make skb-\u0026gt;data point\n to the middle of the outer NSH or Ethernet header because the Ethernet\n header is not pulled by the second nsh_gso_segment().\r\n\r\n (b)\n While restoring skb-\u0026gt;{mac_header,network_header} in 8 \u0026amp; 9,\n nsh_gso_segment() does not assume that the data in the linear\n buffer is shifted.\r\n\r\n However, udp6_ufo_fragment() could shift the data and change\n skb-\u0026gt;mac_header accordingly as demonstrated by syzbot.\r\n\r\n If this happens, even the restored skb-\u0026gt;mac_header points to\n the middle of the outer header.\r\n\r\nIt seems nsh_gso_segment() has never worked with outer headers so far.\r\n\r\nAt the end of nsh_gso_segment(), the outer header must be restored for\nthe segmented skb, instead of the NSH header.\r\n\r\nTo do that, let\u0026apos;s calculate the outer header position relatively from\nthe inner header and set skb-\u0026gt;{data,mac_header,protocol} properly.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\nBUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\nBUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\n ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222\n __netdev_start_xmit include/linux/netdevice.h:4989 [inline]\n netdev_start_xmit include/linux/netdevice.h:5003 [inline]\n xmit_one net/core/dev.c:3547 [inline]\n dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563\n __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n __do_kmalloc_node mm/slub.c:3980 [inline]\n __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001\n kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\n __\n---truncated---(CVE-2024-36933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue\r\n\r\nFix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which\nsyzbot reported [1].\r\n\r\n[1]\nBUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue\r\n\r\nwrite to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:\n sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]\n sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843\n sk_psock_put include/linux/skmsg.h:459 [inline]\n sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648\n unix_release+0x4b/0x80 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0x68/0x150 net/socket.c:1421\n __fput+0x2c1/0x660 fs/file_table.c:422\n __fput_sync+0x44/0x60 fs/file_table.c:507\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close+0x101/0x1b0 fs/open.c:1541\n __x64_sys_close+0x1f/0x30 fs/open.c:1541\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nread to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:\n sk_psock_data_ready include/linux/skmsg.h:464 [inline]\n sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555\n sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606\n sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]\n sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202\n unix_read_skb net/unix/af_unix.c:2546 [inline]\n unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682\n sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223\n unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x140/0x180 net/socket.c:745\n ____sys_sendmsg+0x312/0x410 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x1e9/0x280 net/socket.c:2667\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nvalue changed: 0xffffffff83d7feb0 -\u0026gt; 0x0000000000000000\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\r\n\r\nPrior to this, commit 4cd12c6065df (\u0026quot;bpf, sockmap: Fix NULL pointer\ndereference in sk_psock_verdict_data_ready()\u0026quot;) fixed one NULL pointer\nsimilarly due to no protection of saved_data_ready. Here is another\ndifferent caller causing the same issue because of the same reason. So\nwe should protect it with sk_callback_lock read lock because the writer\nside in the sk_psock_drop() uses \u0026quot;write_lock_bh(\u0026amp;sk-\u0026gt;sk_callback_lock);\u0026quot;.\r\n\r\nTo avoid errors that could happen in future, I move those two pairs of\nlock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()\r\n\r\nIf we fail to allocate propname buffer, we need to drop the reference\ncount we just took. Because the pinctrl_dt_free_maps() includes the\ndroping operation, here we call it directly.(CVE-2024-36959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/rxe: Fix seg fault in rxe_comp_queue_pkt\r\n\r\nIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the\nresp_pkts queue and then a decision is made whether to run the completer\ntask inline or schedule it. Finally the skb is dereferenced to bump a \u0026apos;hw\u0026apos;\nperformance counter. This is wrong because if the completer task is\nalready running in a separate thread it may have already processed the skb\nand freed it which can cause a seg fault. This has been observed\ninfrequently in testing at high scale.\r\n\r\nThis patch fixes this by changing the order of enqueuing the packet until\nafter the counter is accessed.(CVE-2024-38544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ar5523: enable proper endpoint verification\r\n\r\nSyzkaller reports [1] hitting a warning about an endpoint in use\nnot having an expected type to it.\r\n\r\nFix the issue by checking for the existence of all proper\nendpoints with their according types intact.\r\n\r\nSadly, this patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\n------------[ cut here ]------------\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275\n ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]\n ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]\n ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655\n usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573\n hub_port_connect drivers/usb/core/hub.c:5353 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]\n port_event drivers/usb/core/hub.c:5653 [inline]\n hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n \u0026lt;/TASK\u0026gt;(CVE-2024-38565)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nErhard reports netpoll warnings from sungem:\r\n\r\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\r\n\r\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0026apos;t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0026apos;t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.(CVE-2024-38597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix mb_cache_entry\u0026apos;s e_refcnt leak in ext4_xattr_block_cache_find()\r\n\r\nSyzbot reports a warning as follows:\r\n\r\n============================================\nWARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290\nModules linked in:\nCPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7\nRIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375\n generic_shutdown_super+0x136/0x2d0 fs/super.c:641\n kill_block_super+0x44/0x90 fs/super.c:1675\n ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327\n[...]\n============================================\r\n\r\nThis is because when finding an entry in ext4_xattr_block_cache_find(), if\next4_sb_bread() returns -ENOMEM, the ce\u0026apos;s e_refcnt, which has already grown\nin the __entry_find(), won\u0026apos;t be put away, and eventually trigger the above\nissue in mb_cache_destroy() due to reference count leakage.\r\n\r\nSo call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: xattr: fix buffer overflow for invalid xattr\r\n\r\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\r\n\r\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.(CVE-2024-40902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: add the option to have a tty reject a new ldisc\r\n\r\n... and use it to limit the virtual terminals to just N_TTY. They are\nkind of special, and in particular, the \u0026quot;con_write()\u0026quot; routine violates\nthe \u0026quot;writes cannot sleep\u0026quot; rule that some ldiscs rely on.\r\n\r\nThis avoids the\r\n\r\n BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659\r\n\r\nwhen N_GSM has been attached to a virtual console, and gsmld_write()\ncalls con_write() while holding a spinlock, and con_write() then tries\nto get the console lock.(CVE-2024-40966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251xfd: fix infinite loop when xmit fails\r\n\r\nWhen the mcp251xfd_start_xmit() function fails, the driver stops\nprocessing messages, and the interrupt routine does not return,\nrunning indefinitely even after killing the running application.\r\n\r\nError messages:\n[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16\n[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).\n... and repeat forever.\r\n\r\nThe issue can be triggered when multiple devices share the same SPI\ninterface. And there is concurrent access to the bus.\r\n\r\nThe problem occurs because tx_ring-\u0026gt;head increments even if\nmcp251xfd_start_xmit() fails. Consequently, the driver skips one TX\npackage while still expecting a response in\nmcp251xfd_handle_tefif_one().\r\n\r\nResolve the issue by starting a workqueue to write the tx obj\nsynchronously if err = -EBUSY. In case of another error, decrement\ntx_ring-\u0026gt;head, remove skb from the echo stack, and drop the message.\r\n\r\n[mkl: use more imperative wording in patch description](CVE-2024-41088)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\r\n\r\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.(CVE-2024-42070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: fix shared irq handling on driver remove\r\n\r\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.(CVE-2024-42127)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: avoid overflows in dirty throttling logic\r\n\r\nThe dirty throttling logic is interspersed with assumptions that dirty\nlimits in PAGE_SIZE units fit into 32-bit (so that various multiplications\nfit into 64-bits). If limits end up being larger, we will hit overflows,\npossible divisions by 0 etc. Fix these problems by never allowing so\nlarge dirty limits as they have dubious practical value anyway. For\ndirty_bytes / dirty_background_bytes interfaces we can just refuse to set\nso large limits. For dirty_ratio / dirty_background_ratio it isn\u0026apos;t so\nsimple as the dirty limit is computed from the amount of available memory\nwhich can change due to memory hotplug etc. So when converting dirty\nlimits from ratios to numbers of pages, we just don\u0026apos;t allow the result to\nexceed UINT_MAX.\r\n\r\nThis is root-only triggerable problem which occurs when the operator\nsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibceph: fix race between delayed_work() and ceph_monc_stop()\r\n\r\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting(). Both of\nthese can requeue the delayed work which wouldn\u0026apos;t be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn\u0026apos;t mess with the delayed work in order\nto avoid interfering with the hunting interval logic. This part was\nmissed in commit b5d91704f53e (\u0026quot;libceph: behave in mon_fault() if\ncur_mon \u0026lt; 0\u0026quot;) and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u0026gt;auth and monc-\u0026gt;monmap being\nparticularly susceptible to quickly being reused.\r\n\r\nTo fix this:\r\n\r\n- clear monc-\u0026gt;cur_mon and monc-\u0026gt;hunting as part of closing the session\n in ceph_monc_stop()\n- bail from delayed_work() if monc-\u0026gt;cur_mon is cleared, similar to how\n it\u0026apos;s done in mon_fault() and finish_hunting() (based on monc-\u0026gt;hunting)\n- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: configfs: Prevent OOB read/write in usb_string_copy()\r\n\r\nUserspace provided string \u0026apos;s\u0026apos; could trivially have the length zero. Left\nunchecked this will firstly result in an OOB read in the form\n`if (str[0 - 1] == \u0026apos;\\n\u0026apos;) followed closely by an OOB write in the form\n`str[0 - 1] = \u0026apos;\\0\u0026apos;`.\r\n\r\nThere is already a validating check to catch strings that are too long.\nLet\u0026apos;s supply an additional check for invalid strings that are too short.(CVE-2024-42236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: make sure the first directory block is not a hole\r\n\r\nThe syzbot constructs a directory that has no dirblock but is non-inline,\ni.e. the first directory block is a hole. And no errors are reported when\ncreating files in this directory in the following flow.\r\n\r\n ext4_mknod\n ...\n ext4_add_entry\n // Read block 0\n ext4_read_dirblock(dir, block, DIRENT)\n bh = ext4_bread(NULL, inode, block, 0)\n if (!bh \u0026amp;\u0026amp; (type == INDEX || type == DIRENT_HTREE))\n // The first directory block is a hole\n // But type == DIRENT, so no error is reported.\r\n\r\nAfter that, we get a directory block without \u0026apos;.\u0026apos; and \u0026apos;..\u0026apos; but with a valid\ndentry. This may cause some code that relies on dot or dotdot (such as\nmake_indexed_dir()) to crash.\r\n\r\nTherefore when ext4_read_dirblock() finds that the first directory block\nis a hole report that the filesystem is corrupted and return an error to\navoid loading corrupted data from disk causing something bad.(CVE-2024-42304)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes\r\n\r\nIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: adjust \u0026apos;name\u0026apos; buf size of bna_tcb and bna_ccb structures\r\n\r\nTo have enough space to write all possible sprintf() args. Currently\n\u0026apos;name\u0026apos; size is 16, but the first \u0026apos;%s\u0026apos; specifier may already need at\nleast 16 characters, since \u0026apos;bnad-\u0026gt;netdev-\u0026gt;name\u0026apos; is used there.\r\n\r\nFor \u0026apos;%d\u0026apos; specifiers, assume that they require:\n * 1 char for \u0026apos;tx_id + tx_info-\u0026gt;tcb[i]-\u0026gt;id\u0026apos; sum, BNAD_MAX_TXQ_PER_TX is 8\n * 2 chars for \u0026apos;rx_id + rx_info-\u0026gt;rx_ctrl[i].ccb-\u0026gt;id\u0026apos;, BNAD_MAX_RXP_PER_RX\n is 16\r\n\r\nAnd replace sprintf with snprintf.\r\n\r\nDetected using the static analysis tool - Svace.(CVE-2024-43839)",
"id": "OESA-2024-2029",
"modified": "2026-08-06T11:07:30Z",
"published": "2024-08-23T11:07:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2029"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26586"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26598"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27013"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36933"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42236"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43839"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-26586",
"CVE-2024-26598",
"CVE-2024-26602",
"CVE-2024-27013",
"CVE-2024-36020",
"CVE-2024-36880",
"CVE-2024-36900",
"CVE-2024-36904",
"CVE-2024-36914",
"CVE-2024-36933",
"CVE-2024-36938",
"CVE-2024-36959",
"CVE-2024-38544",
"CVE-2024-38565",
"CVE-2024-38597",
"CVE-2024-39276",
"CVE-2024-40902",
"CVE-2024-40966",
"CVE-2024-41088",
"CVE-2024-42070",
"CVE-2024-42127",
"CVE-2024-42131",
"CVE-2024-42232",
"CVE-2024-42236",
"CVE-2024-42304",
"CVE-2024-42310",
"CVE-2024-43839"
]
}
OESA-2024-2031 (CVE-2024-26586)
Vulnerability from osv_openeuler – Published: 2024-08-23 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix stack corruption
When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found.
One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage.
In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required.
Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register.
Add a test case to make sure the machine does not crash when this condition is hit.
[1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 _syssendmsg+0x164/0x260 _sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26586)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes.
Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)
In the Linux kernel, the following vulnerability has been resolved:
net: relax socket state check at accept time.
Christoph reported the following splat:
WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0 Modules linked in: CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759 Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+0x435/0x620 net/socket.c:1929 __sys_accept4_file net/socket.c:1969 [inline] __sys_accept4+0x9b/0x110 net/socket.c:1999 __do_sys_accept net/socket.c:2016 [inline] __se_sys_accept net/socket.c:2013 [inline] __x64_sys_accept+0x7d/0x90 net/socket.c:2013 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x4315f9 Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 </TASK>
The reproducer invokes shutdown() before entering the listener status. After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets"), the above causes the child to reach the accept syscall in FIN_WAIT1 status.
Eric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: add missing firmware sanity checks
Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.(CVE-2024-36880)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during initialization
The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash.
This patch fixes this by registering the devlink after hardware initialization.(CVE-2024-36900)
In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis.
Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else.
To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false.
[0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfxinetcheck_established+0x10/0x10 tcp_v4_connect+0x278/0x530 inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>(CVE-2024-36904)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip on writeback when it's not applicable
[WHY] dynamic memory safety error detector (KASAN) catches and generates error messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not support certain features which are not initialized.
[HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)
In the Linux kernel, the following vulnerability has been resolved:
nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().
syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:
ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP
NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers.
nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment()
- reset skb->network_header
- save the original skb->{mac_heaeder,mac_len} in a local variable
- pull the NSH header
- resets skb->mac_header
- set up skb->mac_len and skb->protocol for the inner protocol.
and does the following for the segmented skb
- set ntohs(ETH_P_NSH) to skb->protocol
- push the NSH header
- restore skb->mac_header
- set skb->mac_header + mac_len to skb->network_header
- restore skb->mac_len
There are two problems in 6-7 and 8-9.
(a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.
Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment().
(b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted.
However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot.
If this happens, even the restored skb->mac_header points to the middle of the outer header.
It seems nsh_gso_segment() has never worked with outer headers so far.
At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header.
To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly.
[0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---(CVE-2024-36933)
In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1].
[1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 _syssendmsg+0x312/0x410 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
value changed: 0xffffffff83d7feb0 -> 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".
To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.(CVE-2024-38544)
In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.(CVE-2024-38597)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)
In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)
In the Linux kernel, the following vulnerability has been resolved:
tty: add the option to have a tty reject a new ldisc
... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on.
This avoids the
BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659
when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock.(CVE-2024-40966)
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Add tx check to prevent skb leak
Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]
The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT.
Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)
In the Linux kernel, the following vulnerability has been resolved:
nvme: avoid double free special payload
If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQF_SPECIAL_LOAD when the request is cleaned.(CVE-2024-41073)
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix double free on error
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free:
kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci]
Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devres_open_group() call failed.(CVE-2024-41087)
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: fix infinite loop when xmit fails
When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application.
Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever.
The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus.
The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one().
Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message.
mkl: use more imperative wording in patch description
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.(CVE-2024-42070)
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area.
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area.
With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early:
[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8
Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded.(CVE-2024-42126)
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid overflows in dirty throttling logic
The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX.
This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayed_work() and ceph_monc_stop()
The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
if (str[0 - 1] == '\n') followed closely by an OOB write in the formstr[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)
In the Linux kernel, the following vulnerability has been resolved:
ext4: make sure the first directory block is not a hole
The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.
ext4_mknod
...
ext4_add_entry
// Read block 0
ext4_read_dirblock(dir, block, DIRENT)
bh = ext4_bread(NULL, inode, block, 0)
if (!bh && (type == INDEX || type == DIRENT_HTREE))
// The first directory block is a hole
// But type == DIRENT, so no error is reported.
After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash.
Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace.(CVE-2024-43839)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.90.0.171.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-136.90.0.171.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix stack corruption\r\n\r\nWhen tc filters are first added to a net device, the corresponding local\nport gets bound to an ACL group in the device. The group contains a list\nof ACLs. In turn, each ACL points to a different TCAM region where the\nfilters are stored. During forwarding, the ACLs are sequentially\nevaluated until a match is found.\r\n\r\nOne reason to place filters in different regions is when they are added\nwith decreasing priorities and in an alternating order so that two\nconsecutive filters can never fit in the same region because of their\nkey usage.\r\n\r\nIn Spectrum-2 and newer ASICs the firmware started to report that the\nmaximum number of ACLs in a group is more than 16, but the layout of the\nregister that configures ACL groups (PAGT) was not updated to account\nfor that. It is therefore possible to hit stack corruption [1] in the\nrare case where more than 16 ACLs in a group are required.\r\n\r\nFix by limiting the maximum ACL group size to the minimum between what\nthe firmware reports and the maximum ACLs that fit in the PAGT register.\r\n\r\nAdd a test case to make sure the machine does not crash when this\ncondition is hit.\r\n\r\n[1]\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120\n[...]\n dump_stack_lvl+0x36/0x50\n panic+0x305/0x330\n __stack_chk_fail+0x15/0x20\n mlxsw_sp_acl_tcam_group_update+0x116/0x120\n mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110\n mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20\n mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0\n mlxsw_sp_acl_rule_add+0x47/0x240\n mlxsw_sp_flower_replace+0x1a9/0x1d0\n tc_setup_cb_add+0xdc/0x1c0\n fl_hw_replace_filter+0x146/0x1f0\n fl_change+0xc17/0x1360\n tc_new_tfilter+0x472/0xb90\n rtnetlink_rcv_msg+0x313/0x3b0\n netlink_rcv_skb+0x58/0x100\n netlink_unicast+0x244/0x390\n netlink_sendmsg+0x1e4/0x440\n ____sys_sendmsg+0x164/0x260\n ___sys_sendmsg+0x9a/0xe0\n __sys_sendmsg+0x7a/0xc0\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache\r\n\r\nThere is a potential UAF scenario in the case of an LPI translation\ncache hit racing with an operation that invalidates the cache, such\nas a DISCARD ITS command. The root of the problem is that\nvgic_its_check_cache() does not elevate the refcount on the vgic_irq\nbefore dropping the lock that serializes refcount changes.\r\n\r\nHave vgic_its_check_cache() raise the refcount on the returned vgic_irq\nand add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: relax socket state check at accept time.\r\n\r\nChristoph reported the following splat:\r\n\r\nWARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0\nModules linked in:\nCPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nRIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759\nCode: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd \u0026lt;0f\u0026gt; 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80\nRSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293\nRAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64\nR10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000\nR13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800\nFS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786\n do_accept+0x435/0x620 net/socket.c:1929\n __sys_accept4_file net/socket.c:1969 [inline]\n __sys_accept4+0x9b/0x110 net/socket.c:1999\n __do_sys_accept net/socket.c:2016 [inline]\n __se_sys_accept net/socket.c:2013 [inline]\n __x64_sys_accept+0x7d/0x90 net/socket.c:2013\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x4315f9\nCode: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00\nRSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b\nRAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004\nRBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300\nR10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055\n \u0026lt;/TASK\u0026gt;\r\n\r\nThe reproducer invokes shutdown() before entering the listener status.\nAfter commit 94062790aedb (\u0026quot;tcp: defer shutdown(SEND_SHUTDOWN) for\nTCP_SYN_RECV sockets\u0026quot;), the above causes the child to reach the accept\nsyscall in FIN_WAIT1 status.\r\n\r\nEric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: qca: add missing firmware sanity checks\r\n\r\nAdd the missing sanity checks when parsing the firmware files before\ndownloading them to avoid accessing and corrupting memory beyond the\nvmalloced buffer.(CVE-2024-36880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix kernel crash when devlink reload during initialization\r\n\r\nThe devlink reload process will access the hardware resources,\nbut the register operation is done before the hardware is initialized.\nSo, processing the devlink reload during initialization may lead to kernel\ncrash.\r\n\r\nThis patch fixes this by registering the devlink after\nhardware initialization.(CVE-2024-36900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Use refcount_inc_not_zero() in tcp_twsk_unique().\r\n\r\nAnderson Nascimento reported a use-after-free splat in tcp_twsk_unique()\nwith nice analysis.\r\n\r\nSince commit ec94c2696f0b (\u0026quot;tcp/dccp: avoid one atomic operation for\ntimewait hashdance\u0026quot;), inet_twsk_hashdance() sets TIME-WAIT socket\u0026apos;s\nsk_refcnt after putting it into ehash and releasing the bucket lock.\r\n\r\nThus, there is a small race window where other threads could try to\nreuse the port during connect() and call sock_hold() in tcp_twsk_unique()\nfor the TIME-WAIT socket with zero refcnt.\r\n\r\nIf that happens, the refcnt taken by tcp_twsk_unique() is overwritten\nand sock_put() will cause underflow, triggering a real use-after-free\nsomewhere else.\r\n\r\nTo avoid the use-after-free, we need to use refcount_inc_not_zero() in\ntcp_twsk_unique() and give up on reusing the port if it returns false.\r\n\r\n[0]:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110\nCPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1\nHardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023\nRIP: 0010:refcount_warn_saturate+0xe5/0x110\nCode: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8\nRSP: 0018:ffffc90006b43b60 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027\nRDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0\nRBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0\nR10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84\nR13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0\nFS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xe5/0x110\n ? __warn+0x81/0x130\n ? refcount_warn_saturate+0xe5/0x110\n ? report_bug+0x171/0x1a0\n ? refcount_warn_saturate+0xe5/0x110\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? refcount_warn_saturate+0xe5/0x110\n tcp_twsk_unique+0x186/0x190\n __inet_check_established+0x176/0x2d0\n __inet_hash_connect+0x74/0x7d0\n ? __pfx___inet_check_established+0x10/0x10\n tcp_v4_connect+0x278/0x530\n __inet_stream_connect+0x10f/0x3d0\n inet_stream_connect+0x3a/0x60\n __sys_connect+0xa8/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0x83/0x170\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7f62c11a885d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d\nRDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003\nRBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0\nR13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0\n \u0026lt;/TASK\u0026gt;(CVE-2024-36904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip on writeback when it\u0026apos;s not applicable\r\n\r\n[WHY]\ndynamic memory safety error detector (KASAN) catches and generates error\nmessages \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot; as writeback connector does not\nsupport certain features which are not initialized.\r\n\r\n[HOW]\nSkip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnsh: Restore skb-\u0026gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().\r\n\r\nsyzbot triggered various splats (see [0] and links) by a crafted GSO\npacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:\r\n\r\n ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP\r\n\r\nNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner\nprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls\nskb_mac_gso_segment() to invoke inner protocol GSO handlers.\r\n\r\nnsh_gso_segment() does the following for the original skb before\ncalling skb_mac_gso_segment()\r\n\r\n 1. reset skb-\u0026gt;network_header\n 2. save the original skb-\u0026gt;{mac_heaeder,mac_len} in a local variable\n 3. pull the NSH header\n 4. resets skb-\u0026gt;mac_header\n 5. set up skb-\u0026gt;mac_len and skb-\u0026gt;protocol for the inner protocol.\r\n\r\nand does the following for the segmented skb\r\n\r\n 6. set ntohs(ETH_P_NSH) to skb-\u0026gt;protocol\n 7. push the NSH header\n 8. restore skb-\u0026gt;mac_header\n 9. set skb-\u0026gt;mac_header + mac_len to skb-\u0026gt;network_header\n 10. restore skb-\u0026gt;mac_len\r\n\r\nThere are two problems in 6-7 and 8-9.\r\n\r\n (a)\n After 6 \u0026amp; 7, skb-\u0026gt;data points to the NSH header, so the outer header\n (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.\r\n\r\n Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),\n skb_pull() in the first nsh_gso_segment() will make skb-\u0026gt;data point\n to the middle of the outer NSH or Ethernet header because the Ethernet\n header is not pulled by the second nsh_gso_segment().\r\n\r\n (b)\n While restoring skb-\u0026gt;{mac_header,network_header} in 8 \u0026amp; 9,\n nsh_gso_segment() does not assume that the data in the linear\n buffer is shifted.\r\n\r\n However, udp6_ufo_fragment() could shift the data and change\n skb-\u0026gt;mac_header accordingly as demonstrated by syzbot.\r\n\r\n If this happens, even the restored skb-\u0026gt;mac_header points to\n the middle of the outer header.\r\n\r\nIt seems nsh_gso_segment() has never worked with outer headers so far.\r\n\r\nAt the end of nsh_gso_segment(), the outer header must be restored for\nthe segmented skb, instead of the NSH header.\r\n\r\nTo do that, let\u0026apos;s calculate the outer header position relatively from\nthe inner header and set skb-\u0026gt;{data,mac_header,protocol} properly.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\nBUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\nBUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\n ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222\n __netdev_start_xmit include/linux/netdevice.h:4989 [inline]\n netdev_start_xmit include/linux/netdevice.h:5003 [inline]\n xmit_one net/core/dev.c:3547 [inline]\n dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563\n __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n __do_kmalloc_node mm/slub.c:3980 [inline]\n __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001\n kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\n __\n---truncated---(CVE-2024-36933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue\r\n\r\nFix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which\nsyzbot reported [1].\r\n\r\n[1]\nBUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue\r\n\r\nwrite to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:\n sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]\n sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843\n sk_psock_put include/linux/skmsg.h:459 [inline]\n sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648\n unix_release+0x4b/0x80 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0x68/0x150 net/socket.c:1421\n __fput+0x2c1/0x660 fs/file_table.c:422\n __fput_sync+0x44/0x60 fs/file_table.c:507\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close+0x101/0x1b0 fs/open.c:1541\n __x64_sys_close+0x1f/0x30 fs/open.c:1541\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nread to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:\n sk_psock_data_ready include/linux/skmsg.h:464 [inline]\n sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555\n sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606\n sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]\n sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202\n unix_read_skb net/unix/af_unix.c:2546 [inline]\n unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682\n sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223\n unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x140/0x180 net/socket.c:745\n ____sys_sendmsg+0x312/0x410 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x1e9/0x280 net/socket.c:2667\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nvalue changed: 0xffffffff83d7feb0 -\u0026gt; 0x0000000000000000\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\r\n\r\nPrior to this, commit 4cd12c6065df (\u0026quot;bpf, sockmap: Fix NULL pointer\ndereference in sk_psock_verdict_data_ready()\u0026quot;) fixed one NULL pointer\nsimilarly due to no protection of saved_data_ready. Here is another\ndifferent caller causing the same issue because of the same reason. So\nwe should protect it with sk_callback_lock read lock because the writer\nside in the sk_psock_drop() uses \u0026quot;write_lock_bh(\u0026amp;sk-\u0026gt;sk_callback_lock);\u0026quot;.\r\n\r\nTo avoid errors that could happen in future, I move those two pairs of\nlock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/rxe: Fix seg fault in rxe_comp_queue_pkt\r\n\r\nIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the\nresp_pkts queue and then a decision is made whether to run the completer\ntask inline or schedule it. Finally the skb is dereferenced to bump a \u0026apos;hw\u0026apos;\nperformance counter. This is wrong because if the completer task is\nalready running in a separate thread it may have already processed the skb\nand freed it which can cause a seg fault. This has been observed\ninfrequently in testing at high scale.\r\n\r\nThis patch fixes this by changing the order of enqueuing the packet until\nafter the counter is accessed.(CVE-2024-38544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nErhard reports netpoll warnings from sungem:\r\n\r\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\r\n\r\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0026apos;t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0026apos;t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.(CVE-2024-38597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix mb_cache_entry\u0026apos;s e_refcnt leak in ext4_xattr_block_cache_find()\r\n\r\nSyzbot reports a warning as follows:\r\n\r\n============================================\nWARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290\nModules linked in:\nCPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7\nRIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375\n generic_shutdown_super+0x136/0x2d0 fs/super.c:641\n kill_block_super+0x44/0x90 fs/super.c:1675\n ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327\n[...]\n============================================\r\n\r\nThis is because when finding an entry in ext4_xattr_block_cache_find(), if\next4_sb_bread() returns -ENOMEM, the ce\u0026apos;s e_refcnt, which has already grown\nin the __entry_find(), won\u0026apos;t be put away, and eventually trigger the above\nissue in mb_cache_destroy() due to reference count leakage.\r\n\r\nSo call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: xattr: fix buffer overflow for invalid xattr\r\n\r\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\r\n\r\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.(CVE-2024-40902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: add the option to have a tty reject a new ldisc\r\n\r\n... and use it to limit the virtual terminals to just N_TTY. They are\nkind of special, and in particular, the \u0026quot;con_write()\u0026quot; routine violates\nthe \u0026quot;writes cannot sleep\u0026quot; rule that some ldiscs rely on.\r\n\r\nThis avoids the\r\n\r\n BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659\r\n\r\nwhen N_GSM has been attached to a virtual console, and gsmld_write()\ncalls con_write() while holding a spinlock, and con_write() then tries\nto get the console lock.(CVE-2024-40966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nibmvnic: Add tx check to prevent skb leak\r\n\r\nBelow is a summary of how the driver stores a reference to an skb during\ntransmit:\n tx_buff[free_map[consumer_index]]-\u0026gt;skb = new_skb;\n free_map[consumer_index] = IBMVNIC_INVALID_MAP;\n consumer_index ++;\nWhere variable data looks like this:\n free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]\n \tconsumer_index^\n tx_buff == [skb=null, skb=\u0026lt;ptr\u0026gt;, skb=\u0026lt;ptr\u0026gt;, skb=null, skb=null]\r\n\r\nThe driver has checks to ensure that free_map[consumer_index] pointed to\na valid index but there was no check to ensure that this index pointed\nto an unused/null skb address. So, if, by some chance, our free_map and\ntx_buff lists become out of sync then we were previously risking an\nskb memory leak. This could then cause tcp congestion control to stop\nsending packets, eventually leading to ETIMEDOUT.\r\n\r\nTherefore, add a conditional to ensure that the skb address is null. If\nnot then warn the user (because this is still a bug that should be\npatched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme: avoid double free special payload\r\n\r\nIf a discard request needs to be retried, and that retry may fail before\na new special payload is added, a double free will result. Clear the\nRQF_SPECIAL_LOAD when the request is cleaned.(CVE-2024-41073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix double free on error\r\n\r\nIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump\nto the err_out label, which will call devres_release_group().\ndevres_release_group() will trigger a call to ata_host_release().\nata_host_release() calls kfree(host), so executing the kfree(host) in\nata_host_alloc() will lead to a double free:\r\n\r\nkernel BUG at mm/slub.c:553!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:kfree+0x2cf/0x2f0\nCode: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da\nRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246\nRAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320\nRDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0\nRBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780\nR13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006\nFS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? kfree+0x2cf/0x2f0\n ? exc_invalid_op+0x50/0x70\n ? kfree+0x2cf/0x2f0\n ? asm_exc_invalid_op+0x1a/0x20\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? kfree+0x2cf/0x2f0\n ata_host_alloc+0xf5/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nEnsure that we will not call kfree(host) twice, by performing the kfree()\nonly if the devres_open_group() call failed.(CVE-2024-41087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251xfd: fix infinite loop when xmit fails\r\n\r\nWhen the mcp251xfd_start_xmit() function fails, the driver stops\nprocessing messages, and the interrupt routine does not return,\nrunning indefinitely even after killing the running application.\r\n\r\nError messages:\n[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16\n[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).\n... and repeat forever.\r\n\r\nThe issue can be triggered when multiple devices share the same SPI\ninterface. And there is concurrent access to the bus.\r\n\r\nThe problem occurs because tx_ring-\u0026gt;head increments even if\nmcp251xfd_start_xmit() fails. Consequently, the driver skips one TX\npackage while still expecting a response in\nmcp251xfd_handle_tefif_one().\r\n\r\nResolve the issue by starting a workqueue to write the tx obj\nsynchronously if err = -EBUSY. In case of another error, decrement\ntx_ring-\u0026gt;head, remove skb from the echo stack, and drop the message.\r\n\r\n[mkl: use more imperative wording in patch description](CVE-2024-41088)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\r\n\r\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.(CVE-2024-42070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.\r\n\r\nnmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel\ncrash when invoked during real mode interrupt handling (e.g. early HMI/MCE\ninterrupt handler) if percpu allocation comes from vmalloc area.\r\n\r\nEarly HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()\nwrapper which invokes nmi_enter/nmi_exit calls. We don\u0026apos;t see any issue when\npercpu allocation is from the embedded first chunk. However with\nCONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu\nallocation can come from the vmalloc area.\r\n\r\nWith kernel command line \u0026quot;percpu_alloc=page\u0026quot; we can force percpu allocation\nto come from vmalloc area and can see kernel crash in machine_check_early:\r\n\r\n[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110\n[ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0\n[ 1.215719] --- interrupt: 200\n[ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)\n[ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0\n[ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8\r\n\r\nFix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu\nfirst chunk is not embedded.(CVE-2024-42126)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: fix shared irq handling on driver remove\r\n\r\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.(CVE-2024-42127)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: avoid overflows in dirty throttling logic\r\n\r\nThe dirty throttling logic is interspersed with assumptions that dirty\nlimits in PAGE_SIZE units fit into 32-bit (so that various multiplications\nfit into 64-bits). If limits end up being larger, we will hit overflows,\npossible divisions by 0 etc. Fix these problems by never allowing so\nlarge dirty limits as they have dubious practical value anyway. For\ndirty_bytes / dirty_background_bytes interfaces we can just refuse to set\nso large limits. For dirty_ratio / dirty_background_ratio it isn\u0026apos;t so\nsimple as the dirty limit is computed from the amount of available memory\nwhich can change due to memory hotplug etc. So when converting dirty\nlimits from ratios to numbers of pages, we just don\u0026apos;t allow the result to\nexceed UINT_MAX.\r\n\r\nThis is root-only triggerable problem which occurs when the operator\nsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibceph: fix race between delayed_work() and ceph_monc_stop()\r\n\r\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting(). Both of\nthese can requeue the delayed work which wouldn\u0026apos;t be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn\u0026apos;t mess with the delayed work in order\nto avoid interfering with the hunting interval logic. This part was\nmissed in commit b5d91704f53e (\u0026quot;libceph: behave in mon_fault() if\ncur_mon \u0026lt; 0\u0026quot;) and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u0026gt;auth and monc-\u0026gt;monmap being\nparticularly susceptible to quickly being reused.\r\n\r\nTo fix this:\r\n\r\n- clear monc-\u0026gt;cur_mon and monc-\u0026gt;hunting as part of closing the session\n in ceph_monc_stop()\n- bail from delayed_work() if monc-\u0026gt;cur_mon is cleared, similar to how\n it\u0026apos;s done in mon_fault() and finish_hunting() (based on monc-\u0026gt;hunting)\n- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: configfs: Prevent OOB read/write in usb_string_copy()\r\n\r\nUserspace provided string \u0026apos;s\u0026apos; could trivially have the length zero. Left\nunchecked this will firstly result in an OOB read in the form\n`if (str[0 - 1] == \u0026apos;\\n\u0026apos;) followed closely by an OOB write in the form\n`str[0 - 1] = \u0026apos;\\0\u0026apos;`.\r\n\r\nThere is already a validating check to catch strings that are too long.\nLet\u0026apos;s supply an additional check for invalid strings that are too short.(CVE-2024-42236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: make sure the first directory block is not a hole\r\n\r\nThe syzbot constructs a directory that has no dirblock but is non-inline,\ni.e. the first directory block is a hole. And no errors are reported when\ncreating files in this directory in the following flow.\r\n\r\n ext4_mknod\n ...\n ext4_add_entry\n // Read block 0\n ext4_read_dirblock(dir, block, DIRENT)\n bh = ext4_bread(NULL, inode, block, 0)\n if (!bh \u0026amp;\u0026amp; (type == INDEX || type == DIRENT_HTREE))\n // The first directory block is a hole\n // But type == DIRENT, so no error is reported.\r\n\r\nAfter that, we get a directory block without \u0026apos;.\u0026apos; and \u0026apos;..\u0026apos; but with a valid\ndentry. This may cause some code that relies on dot or dotdot (such as\nmake_indexed_dir()) to crash.\r\n\r\nTherefore when ext4_read_dirblock() finds that the first directory block\nis a hole report that the filesystem is corrupted and return an error to\navoid loading corrupted data from disk causing something bad.(CVE-2024-42304)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes\r\n\r\nIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: adjust \u0026apos;name\u0026apos; buf size of bna_tcb and bna_ccb structures\r\n\r\nTo have enough space to write all possible sprintf() args. Currently\n\u0026apos;name\u0026apos; size is 16, but the first \u0026apos;%s\u0026apos; specifier may already need at\nleast 16 characters, since \u0026apos;bnad-\u0026gt;netdev-\u0026gt;name\u0026apos; is used there.\r\n\r\nFor \u0026apos;%d\u0026apos; specifiers, assume that they require:\n * 1 char for \u0026apos;tx_id + tx_info-\u0026gt;tcb[i]-\u0026gt;id\u0026apos; sum, BNAD_MAX_TXQ_PER_TX is 8\n * 2 chars for \u0026apos;rx_id + rx_info-\u0026gt;rx_ctrl[i].ccb-\u0026gt;id\u0026apos;, BNAD_MAX_RXP_PER_RX\n is 16\r\n\r\nAnd replace sprintf with snprintf.\r\n\r\nDetected using the static analysis tool - Svace.(CVE-2024-43839)",
"id": "OESA-2024-2031",
"modified": "2026-08-06T11:07:30Z",
"published": "2024-08-23T11:07:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2031"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26586"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26598"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36484"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36933"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41066"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42126"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42236"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43839"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-26586",
"CVE-2024-26598",
"CVE-2024-36484",
"CVE-2024-36880",
"CVE-2024-36900",
"CVE-2024-36904",
"CVE-2024-36914",
"CVE-2024-36933",
"CVE-2024-36938",
"CVE-2024-38544",
"CVE-2024-38597",
"CVE-2024-39276",
"CVE-2024-40902",
"CVE-2024-40966",
"CVE-2024-41066",
"CVE-2024-41073",
"CVE-2024-41087",
"CVE-2024-41088",
"CVE-2024-42070",
"CVE-2024-42126",
"CVE-2024-42127",
"CVE-2024-42131",
"CVE-2024-42232",
"CVE-2024-42236",
"CVE-2024-42304",
"CVE-2024-42310",
"CVE-2024-43839"
]
}
OESA-2025-2802 (CVE-2024-38381)
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:
nfc: nci: Fix uninit-value in nci_rx_work
syzbot reported the following uninit-value access issue [1]
nci_rx_work() parses received packet from ndev->rx_q. It should be validated header size, payload size and total packet size before processing the packet. If an invalid packet is detected, it should be silently discarded.(CVE-2024-38381)
In the Linux kernel, the following vulnerability has been resolved:net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()In the prueth_probe() function, if one of the calls to emac_phy_connect()fails due to of_phy_connect() returning NULL, then the subsequent call tophy_attached_info() will dereference a NULL pointer.Check the return code of emac_phy_connect and fail cleanly if there is anerror.(CVE-2024-38584)
In the Linux kernel, the following vulnerability has been resolved:cpufreq: exit() callback is optionalThe exit() callback is optional and shouldn t be called without checkinga valid pointer first.Also, we must clear freq_table pointer even if the exit() callback isn tpresent.(CVE-2024-38615)
In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn t update the respective globalvariable and after insmod — rmmod — insmod cycle the kerneloopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)
In the Linux kernel, the following vulnerability has been resolved:
enic: Validate length of nl attributes in enic_set_vf_port
enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enic_set_vf_port expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enic_set_vf_port.(CVE-2024-38659)
In the Linux kernel, the following vulnerability has been resolved:riscv: prevent pt_regs corruption for secondary idle threadsTop of the kernel thread stack should be reserved for pt_regs. Howeverthis is not the case for the idle threads of the secondary boot harts.Their stacks overlap with their pt_regs, so both may get corrupted.Similar issue has been fixed for the primary hart, see c7cdd96eca28( riscv: prevent stack corruption by reserving task_pt_regs(p) early ).However that fix was not propagated to the secondary harts. The problemhas been noticed in some CPU hotplug tests with V enabled. The functionsmp_callin stored several registers on stack, corrupting top of pt_regsstructure including status field. As a result, kernel attempted to saveor restore inexistent V context.(CVE-2024-38667)
In the Linux kernel, the following vulnerability has been resolved:jfs: xattr: fix buffer overflow for invalid xattrWhen an xattr size is not what is expected, it is printed out to thekernel log in hex format as a form of debugging. But when that xattrsize is bigger than the expected size, printing it out can cause anaccess off the end of the buffer.Fix this all up by properly restricting the size of the debug hex dumpin the kernel log.(CVE-2024-40902)
In the Linux kernel, the following vulnerability has been resolved:
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
The syzbot fuzzer found that the interrupt-URB completion callback in the cdc-wdm driver was taking too long, and the driver's immediate resubmission of interrupt URBs with -EPROTO status combined with the dummy-hcd emulation to cause a CPU lockup:
cdc_wdm 1-1:1.0: nonzero urb status received: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625] CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idle Modules linked in: irq event stamp: 73096 hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Testing showed that the problem did not occur if the two error messages -- the first two lines above -- were removed; apparently adding material to the kernel log takes a surprisingly large amount of time.
In any case, the best approach for preventing these lockups and to avoid spamming the log with thousands of error messages per second is to ratelimit the two dev_err() calls. Therefore we replace them with dev_err_ratelimited().(CVE-2024-40904)
In the Linux kernel, the following vulnerability has been resolved:nvmet: always initialize cqe.resultThe spec doesn t mandate that the first two double words (aka results)for the command queue entry need to be set to 0 when they are notused (not specified). Though, the target implemention returns 0 for TCPand FC but not for RDMA.Let s make RDMA behave the same and thus explicitly initializing theresult field. This prevents leaking any data from the stack.(CVE-2024-41079)
In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42101)
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:Revert sched/fair: Make sure to try to detach at least one movable task This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.b0defa7ae03ec changed the load balancing logic to ignore env.max_loop ifall tasks examined to that point were pinned. The goal of the patch wasto make it more likely to be able to detach a task buried in a long listof pinned tasks. However, this has the unfortunate side effect ofcreating an O(n) iteration in detach_tasks(), as we now must fullyiterate every task on a cpu if all or most are pinned. Since this loadbalance code is done with rq lock held, and often in softirq context, itis very easy to trigger hard lockups. We observed such hard lockups witha user who affined O(10k) threads to a single cpu.When I discussed this with Vincent he initially suggested that we keepthe limit on the number of tasks to detach, but increase the number oftasks we can search. However, after some back and forth on the mailinglist, he recommended we instead revert the original patch, as it seemslikely no one was actually getting hit by the original issue.(CVE-2024-42245)
In the Linux kernel, the following vulnerability has been resolved:wireguard: allowedips: avoid unaligned 64-bit memory accessesOn the parisc platform, the kernel issues kernel warnings becauseswap_endian() tries to load a 128-bit IPv6 address from an unalignedmemory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)Avoid such unaligned memory accesses by instead using theget_unaligned_be64() helper macro.Jason: replace src[8] in original patch with src+8
In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to don t dirty inode for readonly filesystemsyzbot reports f2fs bug as below:kernel BUG at fs/f2fs/inode.c:933!RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6bThe root cause is:- do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE)- umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panicWhen we try to repair i_current_depth in readonly filesystem, let sskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)
In the Linux kernel, the following vulnerability has been resolved:vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()Since commit 3f8ca2e115e5 ( vhost/scsi: Extract common handling codefrom control queue handler ) a null pointer dereference bug can betriggered when guest sends an SCSI AN request.In vhost_scsi_ctl_handle_vq(), vc.target is assigned with&v_req.tmf.lun[1] within a switch-case block and is then passed tovhost_scsi_get_req() which extracts vc->req and tpg. However, fora VIRTIO_SCSI_T_AN_* request, tpg is not required, so vc.target isset to NULL in this branch. Later, in vhost_scsi_get_req(),vc->target is dereferenced without being checked, leading to a nullpointer dereference bug. This bug can be triggered from guest.When this bug occurs, the vhost_worker process is killed while holdingvq->mutex and the corresponding tpg will remain occupiedindefinitely.Below is the KASAN report:Oops: general protection fault, probably for non-canonical address0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vhost_scsi_get_req+0x165/0x3a0Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 0048 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b604 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00RSP: 0018:ffff888017affb50 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0Call Trace: <TASK> ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350... </TASK>---[ end trace 0000000000000000 ]---Let s add a check in vhost_scsi_get_req.whitespace fixes
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:drm/amd/display: Fix index out of bounds in degamma hardware format translationFixes index out of bounds issue incm_helper_translate_curve_to_degamma_hw_format function. The issuecould occur when the index i exceeds the number of transfer functionpoints (TRANSFER_FUNC_POINTS).The fix adds a check to ensure i is within bounds before accessing thetransfer function points. If i is out of bounds the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow output_tf->tf_pts.red 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow output_tf->tf_pts.green 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow output_tf->tf_pts.blue 1025 <= s32max(CVE-2024-49894)
In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for afb in amdgpu_dm_plane_handle_cursor_update (v2)This commit adds a null check for the afb variable in theamdgpu_dm_plane_handle_cursor_update function. Previously, afb wasassumed to be null, but was used later in the code without a null check.This could potentially lead to a null pointer dereference.Changes since v1:- Moved the null check for afb to the line where afb is used. (Alex)Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed afb could be null (see line 1252)(CVE-2024-49905)
In the Linux kernel, the following vulnerability has been resolved:fbdev: efifb: Register sysfs groups through driver coreThe driver core can register and cleanup sysfs groups already.Make use of that functionality to simplify the error handling andcleanup.Also avoid a UAF race during unregistering where the sysctl attributeswere usable after the info struct was freed.(CVE-2024-49925)
In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix array out-of-bound access in SoC statsCurrently, the ath11k_soc_dp_stats::hal_reo_error array is defined with amaximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()function access ath11k_soc_dp_stats::hal_reo_error using the REOdestination SRNG ring ID, which is incorrect. SRNG ring ID differ fromnormal ring ID, and this usage leads to out-of-bounds array access. To fixthis issue, modify ath11k_dp_process_rx() to use the normal ring IDdirectly instead of the SRNG ring ID to avoid out-of-bounds array access.Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-49930)
In the Linux kernel, the following vulnerability has been resolved:ACPI: PAD: fix crash in exit_round_robin()The kernel occasionally crashes in cpumask_clear_cpu(), which is calledwithin exit_round_robin(), because when executing clear_bit(nr, addr) withnr set to 0xffffffff, the address calculation may cause misalignment withinthe memory, leading to access to an invalid memory address.----------BUG: unable to handle kernel paging request at ffffffffe0740618 ...CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ...RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000eR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000eFS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ...CR2: ffffffffe0740618crash> dis -lr ffffffffc0726923 .../usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 1140xffffffffc0726918 <power_saving_thread+776>: mov %r12d,%r12d/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 3250xffffffffc072691b <power_saving_thread+779>: mov -0x3f8d7de0(,%r12,4),%eax/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 800xffffffffc0726923 <power_saving_thread+787>: lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <pad_busy_cpus_bits>crash> px tsk_in_cpu[14]$66 = 0xffffffffcrash> px 0xffffffffc072692c+0x19cf4$99 = 0xffffffffc0740620crash> sym 0xffffffffc0740620ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]crash> px pad_busy_cpus_bits[0]$42 = 0xfffc0----------To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before callingcpumask_clear_cpu() in exit_round_robin(), just as it is done inround_robin_cpu(). rjw: Subject edit, avoid updates to the same value
In the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb->len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious GSO packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)->pkt_len.(CVE-2024-49948)
In the Linux kernel, the following vulnerability has been resolved:net: avoid potential underflow in qdisc_pkt_len_init() with UFOAfter commit 7c6d2ecbda83 ( net: be more gentle about silly gsorequests coming from user ) virtio_net_hdr_to_skb() had sanity checkto detect malicious attempts from user space to cook a bad GSO packet.Then commit cf9acc90c80ec ( net: virtio_net_hdr_to_skb: counttransport header in UFO ) while fixing one issue, allowed user spaceto cook a GSO packet with the following characteristic :IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.When this packet arrives in qdisc_pkt_len_init(), we end upwith hdr_len = 28 (IPv4 header + UDP header), matching skb->lenThen the following sets gso_segs to 0 :gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size);Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;This leads to the following crash in fq_codel [1]qdisc_pkt_len_init() is best effort, we only want an estimationof the bytes sent on the wire, not crashing the kernel.This patch is fixing this particular issue, a following oneadds more sanity checks for another potential bug.[1][ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 70.724561] #PF: supervisor read access in kernel mode[ 70.724561] #PF: error_code(0x0000) - not-present page[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49All code======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WBCode starting with the faulting instruction=========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C---truncated---(CVE-2024-49949)
In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix uaf in l2cap_connect[Syzbot reported]BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Workqueue: hci2 hci_rx_workCall Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244...Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)
In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix null-ptr-deref when journal load failed.During the mounting process, if journal_reset() fails because of too shortjournal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() callsjbd2_journal_flush()->jbd2_cleanup_journal_tail()->__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()->lock_buffer(journal->j_sb_buffer), resulting in a null-pointerdereference error.To resolve this issue, we should check the JBD2_LOADED flag to ensure thejournal was properly loaded. Additionally, use journal instead ofosb->journal directly to simplify the code.(CVE-2024-49957)
In the Linux kernel, the following vulnerability has been resolved:ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will causeNULL pointer dereference later. rjw: Subject and changelog edits
In the Linux kernel, the following vulnerability has been resolved:static_call: Handle module init failure correctly in static_call_del_module()Module insertion invokes static_call_add_module() to initialize the staticcalls in a module. static_call_add_module() invokes __static_call_init(),which allocates a struct static_call_mod to either encapsulate the built-instatic call sites of the associated key into it so further modules can beadded or to append the module to the module chain.If that allocation fails the function returns with an error code and themodule core invokes static_call_del_module() to clean up eventually addedstatic_call_mod entries.This works correctly, when all keys used by the module were converted overto a module chain before the failure. If not then static_call_del_module()causes a #GP as it blindly assumes that key::mods points to a valid structstatic_call_mod.The problem is that key::mods is not a individual struct member of structstatic_call_key, it s part of a union to save space: union { / bit 0: 0 = mods, 1 = sites / unsigned long type; struct static_call_mod mods; struct static_call_site sites; };key::sites is a pointer to the list of built-in usage sites of the staticcall. The type of the pointer is differentiated by bit 0. A mods pointerhas the bit clear, the sites pointer has the bit set.As static_call_del_module() blidly assumes that the pointer is a validstatic_call_mod type, it fails to check for this failure case anddereferences the pointer to the list of built-in call sites, which isobviously bogus.Cure it by checking whether the key has a sites or a mods pointer.If it s a sites pointer then the key is not to be touched. As the sites arewalked in the same order as in __static_call_init() the site walk can beterminated because all subsequent sites have not been touched by the initcode due to the error exit.If it was converted before the allocation fail, then the inner loop whichsearches for a module match will find nothing.A fail in the second allocation in __static_call_init() is harmless anddoes not require special treatment. The first allocation succeeded andconverted the key to a module chain. That first entry has mod::mod == NULLand mod::next == NULL, so the inner loop of static_call_del_module() willneither find a module match nor a module chain. The next site in the walkwas either already converted, but can t match the module, or it will exitthe outer loop because it has a static_call_site pointer and not astatic_call_mod pointer.(CVE-2024-50002)
In the Linux kernel, the following vulnerability has been resolved:mac802154: Fix potential RCU dereference issue in mac802154_scan_workerIn the mac802154_scan_worker function, the scan_req->type field wasaccessed after the RCU read-side critical section was unlocked. Accordingto RCU usage rules, this is illegal and can lead to unpredictablebehavior, such as accessing memory that has been updated or causinguse-after-free issues.This possible bug was identified using a static analysis tool developedby myself, specifically designed to detect RCU-related issues.To address this, the scan_req->type value is now stored in a localvariable scan_req_type while still within the RCU read-side criticalsection. The scan_req_type is then used after the RCU lock is released,ensuring that the type value is safely accessed without violating RCUrules.(CVE-2024-50005)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".
This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints.
This patch (of 2):
It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled.
This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller.
Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place.
So this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)
In the Linux kernel, the following vulnerability has been resolved:drm: adv7511: Fix use-after-free in adv7533_attach_dsi()The host_node pointer was assigned and freed in adv7533_parse_dt(), andlater, adv7533_attach_dsi() uses the same. Fix this use-after-free issueby dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()in error path of probe() and also in the remove().(CVE-2024-57887)
In the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ( ila: call nf_unregister_net_hooks() sooner )attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: <IRQ> __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+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049(CVE-2024-57900)
In the Linux kernel, the following vulnerability has been resolved:
jfs: add check read-only before txBeginAnon() call
Added a read-only check before calling txBeginAnon in extAlloc
and extRecord. This prevents modification attempts on a read-only
mounted filesystem, avoiding potential errors or crashes.
Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb2_lock
If smb_lock->zero_len has value, ->llist of smb_lock is not delete and flock is old one. It will cause use-after-free on error handling routine.(CVE-2025-21945)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix slab-use-after-free on hdcp_work
[Why] A slab-use-after-free is reported when HDCP is destroyed but the property_validate_dwork queue is still running.
[How] Cancel the delayed work when destroying workqueue.
(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)(CVE-2025-21968)
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:
nfsd: put dl_stid if fail to queue dl_recall
Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we increment the reference count of dl_stid. We expect that after the corresponding work_struct is processed, the reference count of dl_stid will be decremented through the callback function nfsd4_cb_recall_release. However, if the call to nfsd4_run_cb fails, the incremented reference count of dl_stid will not be decremented correspondingly, leading to the following nfs4_stid leak: unreferenced object 0xffff88812067b578 (size 344): comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. backtrace: kmem_cache_alloc+0x4b9/0x700 nfsd4_process_open1+0x34/0x300 nfsd4_open+0x2d1/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 unreferenced object 0xffff8881499f4d28 (size 368): comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... backtrace: kmem_cache_alloc+0x4b9/0x700 nfs4_alloc_stid+0x29/0x210 alloc_init_deleg+0x92/0x2e0 nfs4_set_delegation+0x284/0xc00 nfs4_open_delegation+0x216/0x3f0 nfsd4_process_open2+0x2b3/0xee0 nfsd4_open+0x770/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if fail to queue dl_recall.(CVE-2025-22025)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: don't ignore the return code of svc_proc_register()
Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.
Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs.
svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.(CVE-2025-22026)
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:
ksmbd: add bounds check for create lease context
Add missing bounds check for create lease context.(CVE-2025-22042)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add bounds check for durable handle context
Add missing bounds check for durable handle context.(CVE-2025-22043)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: update channel list in reg notifier instead reg worker
Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list().
But ath11k will immediately execute step 3 after reg_work is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0
Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set, cfg80211 will notify ath11k after step 2 is done.
So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3.
[1] https://patchwork.kernel.org/project/linux-wireless/patch/(CVE-2025-23133)
In the Linux kernel, the following vulnerability has been resolved:
riscv: uprobes: Add missing fence.i after building the XOL buffer
The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions.
This was found running the BPF selftests "test_progs: uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the uprobes tests randomly blew up.(CVE-2025-37822)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue
When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash.
Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.(CVE-2025-37861)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in session logoff
The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user.(CVE-2025-37899)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation
Currently during the multi-link element defragmentation process, the multi-link element length added to the total IEs length when calculating the length of remaining IEs after the multi-link element in cfg80211_defrag_mle(). This could lead to out-of-bounds access if the multi-link element or its corresponding fragment elements are the last elements in the IEs buffer.
To address this issue, correctly calculate the remaining IEs length by deducting the multi-link element end offset from total IEs end offset.(CVE-2025-37973)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: displayport: Fix NULL pointer access
This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.(CVE-2025-37994)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix region locking in hash types
Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.(CVE-2025-37997)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma: Add missing locking
Recent kernels complain about a missing lock in k3-udma.c when the lock validator is enabled:
[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28 [ 4.144867] Hardware name: pp-v12 (DT) [ 4.148648] Workqueue: events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udma_start.isra.0+0x34/0x238 [ 4.165227] lr : udma_start.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udma_start.isra.0+0x34/0x238 [ 4.251509] udma_check_tx_completion+0xd0/0xdc [ 4.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] ret_from_fork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [<ffffffc080a27c7c>] _raw_spin_unlock_irq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [<ffffffc080a1c154>] el1_dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [<ffffffc080037e68>] handle_softirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [<ffffffc080010170>] __do_softirq+0x1c/0x28 [ 4.311559] ---[ end trace 0000000000000000 ]---
This commit adds the missing locking.(CVE-2025-38005)
In the Linux kernel, the following vulnerability has been resolved:
__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput().
Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.(CVE-2025-38058)
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Check return value from memblock_phys_alloc_range()
At least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of contiguous free memory available at this point, the kernel will crash and burn because memblock_phys_alloc_range() returns 0 on failure, which leads memblock_phys_free() to throw the first 4 MiB of physical memory to the wolves.
At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine without the weird reserve allocation.(CVE-2025-38071)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix ECVF vports unload on shutdown flow
Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed.
ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports.
kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220
[] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]---(CVE-2025-38109)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: Initialize ssc before laundromat_work to prevent NULL dereference
In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through nfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized, this can cause NULL pointer dereference.
Normally the delayed start of laundromat_work allows sufficient time for nfsd_ssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4_state_start_net -> nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done -> cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), the delayed work may start before nfsd_ssc initialization finishes.
Fix this by moving nfsd_ssc initialization before starting laundromat_work.(CVE-2025-38231)
In the Linux kernel, the following vulnerability has been resolved:
kernfs: Relax constraint in draining guard
The active reference lifecycle provides the break/unbreak mechanism but the active reference is not truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of kn->active counting. Assuming this mechanism is in place, the WARN check in kernfs_should_drain_open_files() is too sensitive -- it may transiently catch those (rightful) callers between kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen Ridong:
kernfs_remove_by_name_ns kernfs_get_active // active=1
__kernfs_remove // active=0x80000002
kernfs_drain ...
wait_event
//waiting (active == 0x80000001)
kernfs_break_active_protection
// active = 0x80000001
// continue
kernfs_unbreak_active_protection
// active = 0x80000002
...
kernfs_should_drain_open_files
// warning occurs
kernfs_put_active
To avoid the false positives (mind panic_on_warn) remove the check altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with larger rework.)(CVE-2025-38282)
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:
drm/amd/display: Check dce_hwseq before dereferencing it
[WHAT]
hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used.
(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)(CVE-2025-38361)
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix uaf in nbd_genl_connect() error path
There is a use-after-free issue in nbd:
block nbd6: Receive control failed (result -104) block nbd6: shutting down sockets ================================================================== BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022 Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67
CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #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 Workqueue: nbd6-recv recv_work 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:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
nbd_genl_connect() does not properly stop the device on certain error paths after nbd_start_device() has been called. This causes the error path to put nbd->config while recv_work continue to use the config after putting it, leading to use-after-free in recv_work.
This patch moves nbd_start_device() after the backend file creation.(CVE-2025-38443)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Abort __tc_modify_qdisc if parent class does not exist
Lion's patch [1] revealed an ancient bug in the qdisc API. Whenever a user creates/modifies a qdisc specifying as a parent another qdisc, the qdisc API will, during grafting, detect that the user is not trying to attach to a class and reject. However grafting is performed after qdisc_create (and thus the qdiscs' init callback) is executed. In qdiscs that eventually call qdisc_tree_reduce_backlog during init or change (such as fq, hhf, choke, etc), an issue arises. For example, executing the following commands:
sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq
Qdiscs such as fq, hhf, choke, etc unconditionally invoke qdisc_tree_reduce_backlog() in their control path init() or change() which then causes a failure to find the child class; however, that does not stop the unconditional invocation of the assumed child qdisc's qlen_notify with a null class. All these qdiscs make the assumption that class is non-null.
The solution is ensure that qdisc_leaf() which looks up the parent class, and is invoked prior to qdisc_create(), should return failure on not finding the class. In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the parentid doesn't correspond to a class, so that we can detect it earlier on and abort before qdisc_create is called.
[1] https://lore.kernel.org/netdev/(CVE-2025-38457)
In the Linux kernel, the following vulnerability has been resolved:
net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime
Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme.
The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running:
# ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1
When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1].
Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime:
$ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0
Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null
Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the "rx-vlan-filter" feature.
[1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _sys_sendmsg+0xfc/0x180
[2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated---(CVE-2025-38470)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix race condition on qfq_aggregate
A race condition can occur when 'agg' is modified in qfq_change_agg (called during qfq_enqueue) while other threads access it concurrently. For example, qfq_dump_class may trigger a NULL dereference, and qfq_delete_class may cause a use-after-free.
This patch addresses the issue by:
-
Moved qfq_destroy_class into the critical section.
-
Added sch_tree_lock protection to qfq_dump_class and qfq_dump_class_stats.(CVE-2025-38477)
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:
sunrpc: fix handling of server side tls alerts
Scott Mayhew discovered a security exploit in NFS over TLS in tls_alert_recv() due to its assumption it can read data from the msg iterator's kvec..
kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer.
This patch proposes to rework how control messages are setup and used by sock_recvmsg().
If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv.(CVE-2025-38566)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent infinite loop in rt6_nlmsg_size()
While testing prior patch, I was able to trigger an infinite loop in rt6_nlmsg_size() in the following place:
list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); }
This is because fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can confuse rcu readers, because they might no longer see the head of the list.
Restart the loop if f6i->fib6_nsiblings is zero.(CVE-2025-38588)
In the Linux kernel, the following vulnerability has been resolved:
eventpoll: Fix semi-unbounded recursion
Ensure that epoll instances can never form a graph deeper than EP_MAX_NESTS+1 links.
Currently, ep_loop_check_proc() ensures that the graph is loop-free and does some recursion depth checks, but those recursion depth checks don't limit the depth of the resulting tree for two reasons:
- They don't look upwards in the tree.
- If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").
Essentially, the current recursion depth check in ep_loop_check_proc() just serves to prevent it from recursing too deeply while checking for loops.
A more thorough check is done in reverse_path_check() after the new graph edge has already been created; this checks, among other things, that no paths going upwards from any non-epoll file with a length of more than 5 edges exist. However, this check does not apply to non-epoll files.
As a result, it is possible to recurse to a depth of at least roughly 500, tested on v6.15. (I am unsure if deeper recursion is possible; and this may have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion problem").)
To fix it:
- In ep_loop_check_proc(), note the subtree depth of each visited node, and use subtree depths for the total depth calculation even when a subtree has already been visited.
- Add ep_get_upwards_depth_proc() for similarly determining the maximum depth of an upwards walk.
- In ep_loop_check(), use these values to limit the total path length between epoll nodes to EP_MAX_NESTS edges.(CVE-2025-38614)
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:
rv: Use strings in da monitors tracepoints
Using DA monitors tracepoints with KASAN enabled triggers the following warning:
BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200 trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0
This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g. the next automaton's data in this case). The error is harmless as, while printing the string, we stop at the null terminator, but it should still be fixed.
Use the __string facilities while defining the tracepoints to avoid reading out of bound memory.(CVE-2025-38636)
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:
netlink: avoid infinite retry looping in netlink_unicast()
netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:
rmem < READ_ONCE(sk->sk_rcvbuf)
to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:
rmem + skb->truesize > READ_ONCE(sk->sk_rcvbuf)
The checks don't cover the case when skb->truesize + sk->sk_rmem_alloc is equal to sk->sk_rcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:
rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dump_stack lib/dump_stack.c:120 nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105 nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62 rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335 rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590 update_process_times kernel/time/timer.c:1953 tick_sched_handle kernel/time/tick-sched.c:227 tick_sched_timer kernel/time/tick-sched.c:1399 __hrtimer_run_queues kernel/time/hrtimer.c:1652 hrtimer_interrupt kernel/time/hrtimer.c:1717 __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113 asm_call_irq_on_stack arch/x86/entry/entry_64.S:808 </IRQ>
netlink_attachskb net/netlink/af_netlink.c:1234 netlink_unicast net/netlink/af_netlink.c:1349 kauditd_send_queue kernel/audit.c:776 kauditd_thread kernel/audit.c:897 kthread kernel/kthread.c:328 ret_from_fork arch/x86/entry/entry_64.S:304
Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.
Found by Linux Verification Center (linuxtesting.org).(CVE-2025-38727)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()
The function mod_hdcp_hdcp1_create_session() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference.
Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
This is similar to the commit c3e9826a2202 ("drm/amd/display: Add null pointer check for get_first_active_display()").
(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)(CVE-2025-39675)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix backlog accounting in qdisc_dequeue_internal
This issue applies for the following qdiscs: hhf, fq, fq_codel, and fq_pie, and occurs in their change handlers when adjusting to the new limit. The problem is the following in the values passed to the subsequent qdisc_tree_reduce_backlog call given a tbf parent:
When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers.
One can observe this issue with the following (with tc patched to support a limit of 0):
export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo
The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0).
To fix this issue, the codepath for all clients of qdisc_dequeue_internal has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel. qdisc_dequeue_internal handles the backlog adjustments for all cases that do not directly use the dequeue handler.
The old fq_codel_change limit adjustment loop accumulated the arguments to the subsequent qdisc_tree_reduce_backlog call through the cstats field. However, this is confusing and error prone as fq_codel_dequeue could also potentially mutate this field (which qdisc_dequeue_internal calls in the non gso_skb case), so we have unified the code here with other qdiscs.(CVE-2025-39677)
In the Linux kernel, the following vulnerability has been resolved:
comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()
syzbot reports a KMSAN kernel-infoleak in do_insn_ioctl(). A kernel
buffer is allocated to hold insn->n samples (each of which is an
unsigned int). For some instruction types, insn->n samples are
copied back to user-space, unless an error code is being returned. The
problem is that not all the instruction handlers that need to return
data to userspace fill in the whole insn->n samples, so that there is
an information leak. There is a similar syzbot report for
do_insnlist_ioctl(), although it does not have a reproducer for it at
the time of writing.
One culprit is insn_rw_emulate_bits() which is used as the handler for
INSN_READ or INSN_WRITE instructions for subdevices that do not have
a specific handler for that instruction, but do have an INSN_BITS
handler. For INSN_READ it only fills in at most 1 sample, so if
insn->n is greater than 1, the remaining insn->n - 1 samples copied
to userspace will be uninitialized kernel data.
Another culprit is vm80xx_ai_insn_read() in the "vm80xx" driver. It
never returns an error, even if it fails to fill the buffer.
Fix it in do_insn_ioctl() and do_insnlist_ioctl() by making sure
that uninitialized parts of the allocated buffer are zeroed before
handling each instruction.
Thanks to Arnaud Lecomte for their fix to do_insn_ioctl(). That fix
replaced the call to kmalloc_array() with kcalloc(), but it is not
always necessary to clear the whole buffer.(CVE-2025-39684)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix a race when updating an existing write
After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head.
So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().(CVE-2025-39697)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix memory corruption when FW resources change during ifdown
bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1.
In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings().
Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.(CVE-2025-39810)
In the Linux kernel, the following vulnerability has been resolved:
efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare
Observed on kernel 6.6 (present on master as well):
BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0
If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename:
T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list
lookup_open
d_alloc_parallel
__d_lookup_rcu
__d_lookup_rcu_op_compare
hlist_bl_for_each_entry_rcu
// invalid dentry can be retrieved
->d_compare
efivarfs_d_compare
// oob
Fix it by checking 'guid' before cmp.(CVE-2025-39817)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix race with concurrent opens in rename(2)
Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file.
Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target.(CVE-2025-39825)
In the Linux kernel, the following vulnerability has been resolved:
fs: writeback: fix use-after-free in __mark_inode_dirty()
An use-after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching.
CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 ...... pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mark_inode_dirty+0x124/0x418 lr : __mark_inode_dirty+0x118/0x418 sp : ffffffc08c9dbbc0 ........ Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198
Root cause is:
systemd-random-seed kworker
___mark_inode_dirty inode_switch_wbs_work_fn
spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue
Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished.(CVE-2025-39866)
In the Linux kernel, the following vulnerability has been resolved:
kernfs: Fix UAF in polling when open file is released
A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism:
BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1
psi_trigger_poll+0x3c/0x140 cgroup_pressure_poll+0x70/0xa0 cgroup_file_poll+0x8c/0x100 kernfs_fop_poll+0x11c/0x1c0 ep_item_poll.isra.0+0x188/0x2c0
Allocated by task 1: cgroup_file_open+0x88/0x388 kernfs_fop_open+0x73c/0xaf0 do_dentry_open+0x5fc/0x1200 vfs_open+0xa0/0x3f0 do_open+0x7e8/0xd08 path_openat+0x2fc/0x6b0 do_filp_open+0x174/0x368
Freed by task 8462: cgroup_file_release+0x130/0x1f8 kernfs_drain_open_files+0x17c/0x440 kernfs_drain+0x2dc/0x360 kernfs_show+0x1b8/0x288 cgroup_file_show+0x150/0x268 cgroup_pressure_write+0x1dc/0x340 cgroup_file_write+0x274/0x548
Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure
The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv
epolling disable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epoll_wait kernfs_fop_poll kernfs_get_active = true echo 0 > cgroup.pressure ... cgroup_file_show kernfs_show // inactive kn kernfs_drain_open_files cft->release(of); kfree(ctx); ... kernfs_get_active = false echo 1 > cgroup.pressure kernfs_show kernfs_activate_one(kn); kernfs_fop_poll kernfs_get_active = true cgroup_file_poll psi_trigger_poll // UAF ... end: close(fd)
To address this issue, introduce kernfs_get_active_of() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfs_get_active() with kernfs_get_active_of() to prevent further operations on released file descriptors.(CVE-2025-39881)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path
If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration later than the first, the error path wants to free the IRQs requested so far. However, it uses the wrong dev_id argument for free_irq(), so it does not free the IRQs correctly and instead triggers the warning:
Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: <TASK> free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 _syssendmsg+0x3a2/0x3d0 _sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]---
Use the same dev_id for free_irq() as for request_irq().
I tested this with inserting code to fail intentionally.(CVE-2025-39911)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Harden uplink netdev access against device unbind
The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic.
BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: <TASK> mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use.(CVE-2025-39947)
In the Linux kernel, the following vulnerability has been resolved:
media: tuner: xc5000: Fix use-after-free in xc5000_release
The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv.
A typical race condition is illustrated below:
CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated.
A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here.
This bug was initially identified through static analysis.
hverkuil: fix typo in Subject: tunner -> tuner
In the Linux kernel, the following vulnerability has been resolved:
media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove
The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device.
A typical race condition is illustrated below:
CPU 0 (remove) | CPU 1 (delayed work callback) flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAF
This is confirmed by a KASAN report:
================================================================== BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfxruntimer_base.part.0+0x10/0x10 ? pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ> ...
Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30
Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated.
This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug.(CVE-2025-39996)
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID
Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID.
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID.
In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require entities to have a non-zero unique ID"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time.
This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings.
In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid.
Here is a sample stack trace for one of those cases.
[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---(CVE-2025-40016)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: fix uninit-value in squashfs_get_parent
Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.
This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory.
Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field.
unsigned int parent_ino = squashfs_i(inode)->parent;
Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access.
The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned.
Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0.(CVE-2025-40049)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix crypto buffers in non-linear memory
The crypto API, through the scatterlist API, expects input buffers to be in linear memory. We handle this with the cifs_sg_set_buf() helper that converts vmalloc'd memory to their corresponding pages.
However, when we allocate our aead_request buffer (@creq in smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly puts aead_request->__ctx in vmalloc area.
AEAD algorithm then uses ->__ctx for its private/internal data and operations, and uses sg_set_buf() for such data on a few places.
This works fine as long as @creq falls into kmalloc zone (small requests) or vmalloc'd memory is still within linear range.
Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too many tasks will increment the base stacks' addresses to a point where virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that happens.
In practice: too many parallel reads and writes on an encrypted mount will trigger this bug.
To fix this, always alloc @creq with kmalloc() instead. Also drop the @sensitive_size variable/arguments since kfree_sensitive() doesn't need it.
Backtrace:
[ 945.272081] ------------[ cut here ]------------ [ 945.272774] kernel BUG at include/linux/scatterlist.h:209! [ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary) [ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 [ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2) [ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220 [ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b [ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246 [ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030 [ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070 [ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000 [ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070 [ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010 [ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000 [ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0 [ 945.286683] Call Trace: [ 945.286952] <TASK> [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs] [ 945.287719] crypto_gcm_encrypt+0x36/0xe0 [ 945.288152] crypt_message+0x54a/0xad0 [cifs] [ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs] [ 945.289300] smb_send_rqst+0xa3/0x160 [cifs] [ 945.289944] cifs_call_async+0x178/0x340 [cifs] [ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs] [ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs] [ 945.291759] ? find_held_lock+0x32/0x90 [ 945.292212] ? netfs_advance_write+0xf2/0x310 [ 945.292723] netfs_advance_write+0xf2/0x310 [ 945.293210] netfs_write_folio+0x346/0xcc0 [ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10 [ 945.294250] netfs_writepages+0x117/0x460 [ 945.294724] do_writepages+0xbe/0x170 [ 945.295152] ? find_held_lock+0x32/0x90 [ 945.295600] ? kvm_sched_clock_read+0x11/0x20 [ 945.296103] __writeback_single_inode+0x56/0x4b0 [ 945.296643] writeback_sb_inodes+0x229/0x550 [ 945.297140] __writeback_inodes_wb+0x4c/0xe0 [ 945.297642] wb_writeback+0x2f1/0x3f0 [ 945.298069] wb_workfn+0x300/0x490 [ 945.298472] process_one_work+0x1fe/0x590 [ 945.298949] worker_thread+0x1ce/0x3c0 [ 945.299397] ? __pfx_worker_thread+0x10/0x10 [ 945.299900] kthr ---truncated---(CVE-2025-40052)
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Disallow dirty tracking if incoherent page walk
Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work.
The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:
"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault."
To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported.(CVE-2025-40058)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix race in do_task() when draining
When do_task() exhausts its iteration budget (!ret), it sets the state to TASK_STATE_IDLE to reschedule, without a secondary check on the current task->state. This can overwrite the TASK_STATE_DRAINING state set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().
While state changes are protected by a spinlock, both rxe_cleanup_task() and rxe_disable_task() release the lock while waiting for the task to finish draining in the while(!is_done(task)) loop. The race occurs if do_task() hits its iteration limit and acquires the lock in this window. The cleanup logic may then proceed while the task incorrectly reschedules itself, leading to a potential use-after-free.
This bug was introduced during the migration from tasklets to workqueues, where the special handling for the draining case was lost.
Fix this by restoring the original pre-migration behavior. If the state is TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the task to finish its work, so that a subsequent iteration can reach the switch statement and correctly transition the state to TASK_STATE_DRAINED, stopping the task as intended.(CVE-2025-40061)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: start using dst_dev_rcu()
Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.
Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(), ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().(CVE-2025-40074)
In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: use dst_dev_net_rcu()
Replace three dst_dev() with a lockdep enabled helper.(CVE-2025-40075)
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: fix mailbox API compatibility by negotiating supported features
There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API.
This convention has been broken since introducing API 1.4. Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself.
Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes.
The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX.
To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox.
New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op.
Features negotiation mechanism gives possibility to be extended with new features when needed in the future.(CVE-2025-40104)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping
When an invalid value is passed via quirk option, currently bytcr_rt5640 driver just ignores and leaves as is, which may lead to unepxected results like OOB access.
This patch adds the sanity check and corrects the input mapping to the certain default value if an invalid value is passed.(CVE-2025-40121)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: use RCU in ip6_xmit()
Use RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent possible UAF.(CVE-2025-40135)
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)
In the Linux kernel, the following vulnerability has been resolved:
tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().
get_netdev_for_sock() is called during setsockopt(), so not under RCU.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dst_dev_rcu().
Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.(CVE-2025-40149)
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: debugfs: Fix legacy mode page table dump logic
In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like:
Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490 ...
Avoid walking the page table if TT is not 00b or 01b.(CVE-2025-40155)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: use RCU in ip6_output()
Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent possible UAF.
We can remove rcu_read_lock()/rcu_read_unlock() pairs from ip6_finish_output2().(CVE-2025-40158)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-source-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"perf-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"python3-perf-6.6.0-127.0.0.113.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-127.0.0.113.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-127.0.0.113.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-source-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"perf-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"python3-perf-6.6.0-127.0.0.113.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-127.0.0.113.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-127.0.0.113.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix uninit-value in nci_rx_work\n\nsyzbot reported the following uninit-value access issue [1]\n\nnci_rx_work() parses received packet from ndev-\u0026gt;rx_q. It should be\nvalidated header size, payload size and total packet size before\nprocessing the packet. If an invalid packet is detected, it should be\nsilently discarded.(CVE-2024-38381)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()In the prueth_probe() function, if one of the calls to emac_phy_connect()fails due to of_phy_connect() returning NULL, then the subsequent call tophy_attached_info() will dereference a NULL pointer.Check the return code of emac_phy_connect and fail cleanly if there is anerror.(CVE-2024-38584)\n\nIn the Linux kernel, the following vulnerability has been resolved:cpufreq: exit() callback is optionalThe exit() callback is optional and shouldn t be called without checkinga valid pointer first.Also, we must clear freq_table pointer even if the exit() callback isn tpresent.(CVE-2024-38615)\n\nIn the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn t update the respective globalvariable and after insmod \u2014 rmmod \u2014 insmod cycle the kerneloopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nenic: Validate length of nl attributes in enic_set_vf_port\n\nenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE\nis of length PORT_PROFILE_MAX and that the nl attributes\nIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.\nThese attributes are validated (in the function do_setlink in rtnetlink.c)\nusing the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE\nas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and\nIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation\nusing the policy is for the max size of the attributes and not on exact\nsize so the length of these attributes might be less than the sizes that\nenic_set_vf_port expects. This might cause an out of bands\nread access in the memcpys of the data of these\nattributes in enic_set_vf_port.(CVE-2024-38659)\n\nIn the Linux kernel, the following vulnerability has been resolved:riscv: prevent pt_regs corruption for secondary idle threadsTop of the kernel thread stack should be reserved for pt_regs. Howeverthis is not the case for the idle threads of the secondary boot harts.Their stacks overlap with their pt_regs, so both may get corrupted.Similar issue has been fixed for the primary hart, see c7cdd96eca28( riscv: prevent stack corruption by reserving task_pt_regs(p) early ).However that fix was not propagated to the secondary harts. The problemhas been noticed in some CPU hotplug tests with V enabled. The functionsmp_callin stored several registers on stack, corrupting top of pt_regsstructure including status field. As a result, kernel attempted to saveor restore inexistent V context.(CVE-2024-38667)\n\nIn the Linux kernel, the following vulnerability has been resolved:jfs: xattr: fix buffer overflow for invalid xattrWhen an xattr size is not what is expected, it is printed out to thekernel log in hex format as a form of debugging. But when that xattrsize is bigger than the expected size, printing it out can cause anaccess off the end of the buffer.Fix this all up by properly restricting the size of the debug hex dumpin the kernel log.(CVE-2024-40902)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages\n\nThe syzbot fuzzer found that the interrupt-URB completion callback in\nthe cdc-wdm driver was taking too long, and the driver\u0026apos;s immediate\nresubmission of interrupt URBs with -EPROTO status combined with the\ndummy-hcd emulation to cause a CPU lockup:\n\ncdc_wdm 1-1:1.0: nonzero urb status received: -71\ncdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes\nwatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]\nCPU#0 Utilization every 4s during lockup:\n\t#1: 98% system,\t 0% softirq,\t 3% hardirq,\t 0% idle\n\t#2: 98% system,\t 0% softirq,\t 3% hardirq,\t 0% idle\n\t#3: 98% system,\t 0% softirq,\t 3% hardirq,\t 0% idle\n\t#4: 98% system,\t 0% softirq,\t 3% hardirq,\t 0% idle\n\t#5: 98% system,\t 1% softirq,\t 3% hardirq,\t 0% idle\nModules linked in:\nirq event stamp: 73096\nhardirqs last enabled at (73095): [\u0026lt;ffff80008037bc00\u0026gt;] console_emit_next_record kernel/printk/printk.c:2935 [inline]\nhardirqs last enabled at (73095): [\u0026lt;ffff80008037bc00\u0026gt;] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994\nhardirqs last disabled at (73096): [\u0026lt;ffff80008af10b00\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\nhardirqs last disabled at (73096): [\u0026lt;ffff80008af10b00\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\nsoftirqs last enabled at (73048): [\u0026lt;ffff8000801ea530\u0026gt;] softirq_handle_end kernel/softirq.c:400 [inline]\nsoftirqs last enabled at (73048): [\u0026lt;ffff8000801ea530\u0026gt;] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582\nsoftirqs last disabled at (73043): [\u0026lt;ffff800080020de8\u0026gt;] __do_softirq+0x14/0x20 kernel/softirq.c:588\nCPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n\nTesting showed that the problem did not occur if the two error\nmessages -- the first two lines above -- were removed; apparently adding\nmaterial to the kernel log takes a surprisingly large amount of time.\n\nIn any case, the best approach for preventing these lockups and to\navoid spamming the log with thousands of error messages per second is\nto ratelimit the two dev_err() calls. Therefore we replace them with\ndev_err_ratelimited().(CVE-2024-40904)\n\nIn the Linux kernel, the following vulnerability has been resolved:nvmet: always initialize cqe.resultThe spec doesn t mandate that the first two double words (aka results)for the command queue entry need to be set to 0 when they are notused (not specified). Though, the target implemention returns 0 for TCPand FC but not for RDMA.Let s make RDMA behave the same and thus explicitly initializing theresult field. This prevents leaking any data from the stack.(CVE-2024-41079)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42101)\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:Revert sched/fair: Make sure to try to detach at least one movable task This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.b0defa7ae03ec changed the load balancing logic to ignore env.max_loop ifall tasks examined to that point were pinned. The goal of the patch wasto make it more likely to be able to detach a task buried in a long listof pinned tasks. However, this has the unfortunate side effect ofcreating an O(n) iteration in detach_tasks(), as we now must fullyiterate every task on a cpu if all or most are pinned. Since this loadbalance code is done with rq lock held, and often in softirq context, itis very easy to trigger hard lockups. We observed such hard lockups witha user who affined O(10k) threads to a single cpu.When I discussed this with Vincent he initially suggested that we keepthe limit on the number of tasks to detach, but increase the number oftasks we can search. However, after some back and forth on the mailinglist, he recommended we instead revert the original patch, as it seemslikely no one was actually getting hit by the original issue.(CVE-2024-42245)\n\nIn the Linux kernel, the following vulnerability has been resolved:wireguard: allowedips: avoid unaligned 64-bit memory accessesOn the parisc platform, the kernel issues kernel warnings becauseswap_endian() tries to load a 128-bit IPv6 address from an unalignedmemory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)Avoid such unaligned memory accesses by instead using theget_unaligned_be64() helper macro.[Jason: replace src[8] in original patch with src+8](CVE-2024-42247)\n\nIn the Linux kernel, the following vulnerability has been resolved:f2fs: fix to don t dirty inode for readonly filesystemsyzbot reports f2fs bug as below:kernel BUG at fs/f2fs/inode.c:933!RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6bThe root cause is:- do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE)- umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panicWhen we try to repair i_current_depth in readonly filesystem, let sskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)\n\nIn the Linux kernel, the following vulnerability has been resolved:vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()Since commit 3f8ca2e115e5 ( vhost/scsi: Extract common handling codefrom control queue handler ) a null pointer dereference bug can betriggered when guest sends an SCSI AN request.In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with`\u0026amp;v_req.tmf.lun[1]` within a switch-case block and is then passed tovhost_scsi_get_req() which extracts `vc-\u0026gt;req` and `tpg`. However, fora `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` isset to NULL in this branch. Later, in vhost_scsi_get_req(),`vc-\u0026gt;target` is dereferenced without being checked, leading to a nullpointer dereference bug. This bug can be triggered from guest.When this bug occurs, the vhost_worker process is killed while holding`vq-\u0026gt;mutex` and the corresponding tpg will remain occupiedindefinitely.Below is the KASAN report:Oops: general protection fault, probably for non-canonical address0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vhost_scsi_get_req+0x165/0x3a0Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 0048 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 \u0026lt;0f\u0026gt; b604 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00RSP: 0018:ffff888017affb50 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0Call Trace: \u0026lt;TASK\u0026gt; ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350... \u0026lt;/TASK\u0026gt;---[ end trace 0000000000000000 ]---Let s add a check in vhost_scsi_get_req.[whitespace fixes](CVE-2024-49863)\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:drm/amd/display: Fix index out of bounds in degamma hardware format translationFixes index out of bounds issue in`cm_helper_translate_curve_to_degamma_hw_format` function. The issuecould occur when the index i exceeds the number of transfer functionpoints (TRANSFER_FUNC_POINTS).The fix adds a check to ensure i is within bounds before accessing thetransfer function points. If i is out of bounds the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow output_tf-\u0026gt;tf_pts.red 1025 \u0026lt;= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow output_tf-\u0026gt;tf_pts.green 1025 \u0026lt;= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow output_tf-\u0026gt;tf_pts.blue 1025 \u0026lt;= s32max(CVE-2024-49894)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for afb in amdgpu_dm_plane_handle_cursor_update (v2)This commit adds a null check for the afb variable in theamdgpu_dm_plane_handle_cursor_update function. Previously, afb wasassumed to be null, but was used later in the code without a null check.This could potentially lead to a null pointer dereference.Changes since v1:- Moved the null check for afb to the line where afb is used. (Alex)Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed afb could be null (see line 1252)(CVE-2024-49905)\n\nIn the Linux kernel, the following vulnerability has been resolved:fbdev: efifb: Register sysfs groups through driver coreThe driver core can register and cleanup sysfs groups already.Make use of that functionality to simplify the error handling andcleanup.Also avoid a UAF race during unregistering where the sysctl attributeswere usable after the info struct was freed.(CVE-2024-49925)\n\nIn the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix array out-of-bound access in SoC statsCurrently, the ath11k_soc_dp_stats::hal_reo_error array is defined with amaximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()function access ath11k_soc_dp_stats::hal_reo_error using the REOdestination SRNG ring ID, which is incorrect. SRNG ring ID differ fromnormal ring ID, and this usage leads to out-of-bounds array access. To fixthis issue, modify ath11k_dp_process_rx() to use the normal ring IDdirectly instead of the SRNG ring ID to avoid out-of-bounds array access.Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-49930)\n\nIn the Linux kernel, the following vulnerability has been resolved:ACPI: PAD: fix crash in exit_round_robin()The kernel occasionally crashes in cpumask_clear_cpu(), which is calledwithin exit_round_robin(), because when executing clear_bit(nr, addr) withnr set to 0xffffffff, the address calculation may cause misalignment withinthe memory, leading to access to an invalid memory address.----------BUG: unable to handle kernel paging request at ffffffffe0740618 ...CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ...RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 \u0026lt;f0\u0026gt; 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000eR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000eFS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ...CR2: ffffffffe0740618crash\u0026gt; dis -lr ffffffffc0726923 .../usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 1140xffffffffc0726918 \u0026lt;power_saving_thread+776\u0026gt;: mov %r12d,%r12d/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 3250xffffffffc072691b \u0026lt;power_saving_thread+779\u0026gt;: mov -0x3f8d7de0(,%r12,4),%eax/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 800xffffffffc0726923 \u0026lt;power_saving_thread+787\u0026gt;: lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 \u0026lt;pad_busy_cpus_bits\u0026gt;crash\u0026gt; px tsk_in_cpu[14]$66 = 0xffffffffcrash\u0026gt; px 0xffffffffc072692c+0x19cf4$99 = 0xffffffffc0740620crash\u0026gt; sym 0xffffffffc0740620ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]crash\u0026gt; px pad_busy_cpus_bits[0]$42 = 0xfffc0----------To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before callingcpumask_clear_cpu() in exit_round_robin(), just as it is done inround_robin_cpu().[ rjw: Subject edit, avoid updates to the same value ](CVE-2024-49935)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb-\u0026gt;len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious GSO packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)-\u0026gt;pkt_len.(CVE-2024-49948)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: avoid potential underflow in qdisc_pkt_len_init() with UFOAfter commit 7c6d2ecbda83 ( net: be more gentle about silly gsorequests coming from user ) virtio_net_hdr_to_skb() had sanity checkto detect malicious attempts from user space to cook a bad GSO packet.Then commit cf9acc90c80ec ( net: virtio_net_hdr_to_skb: counttransport header in UFO ) while fixing one issue, allowed user spaceto cook a GSO packet with the following characteristic :IPv4 SKB_GSO_UDP, gso_size=3, skb-\u0026gt;len = 28.When this packet arrives in qdisc_pkt_len_init(), we end upwith hdr_len = 28 (IPv4 header + UDP header), matching skb-\u0026gt;lenThen the following sets gso_segs to 0 :gso_segs = DIV_ROUND_UP(skb-\u0026gt;len - hdr_len, shinfo-\u0026gt;gso_size);Then later we set qdisc_skb_cb(skb)-\u0026gt;pkt_len to back to zero :/qdisc_skb_cb(skb)-\u0026gt;pkt_len += (gso_segs - 1) * hdr_len;This leads to the following crash in fq_codel [1]qdisc_pkt_len_init() is best effort, we only want an estimationof the bytes sent on the wire, not crashing the kernel.This patch is fixing this particular issue, a following oneadds more sanity checks for another potential bug.[1][ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 70.724561] #PF: supervisor read access in kernel mode[ 70.724561] #PF: error_code(0x0000) - not-present page[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 \u0026lt;49\u0026gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49All code======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx \u0026lt;-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WBCode starting with the faulting instruction=========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C---truncated---(CVE-2024-49949)\n\nIn the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix uaf in l2cap_connect[Syzbot reported]BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Workqueue: hci2 hci_rx_workCall Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244...Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)\n\nIn the Linux kernel, the following vulnerability has been resolved:ocfs2: fix null-ptr-deref when journal load failed.During the mounting process, if journal_reset() fails because of too shortjournal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() callsjbd2_journal_flush()-\u0026gt;jbd2_cleanup_journal_tail()-\u0026gt;__jbd2_update_log_tail()-\u0026gt;jbd2_journal_update_sb_log_tail()-\u0026gt;lock_buffer(journal-\u0026gt;j_sb_buffer), resulting in a null-pointerdereference error.To resolve this issue, we should check the JBD2_LOADED flag to ensure thejournal was properly loaded. Additionally, use journal instead ofosb-\u0026gt;journal directly to simplify the code.(CVE-2024-49957)\n\nIn the Linux kernel, the following vulnerability has been resolved:ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will causeNULL pointer dereference later.[ rjw: Subject and changelog edits ](CVE-2024-49962)\n\nIn the Linux kernel, the following vulnerability has been resolved:static_call: Handle module init failure correctly in static_call_del_module()Module insertion invokes static_call_add_module() to initialize the staticcalls in a module. static_call_add_module() invokes __static_call_init(),which allocates a struct static_call_mod to either encapsulate the built-instatic call sites of the associated key into it so further modules can beadded or to append the module to the module chain.If that allocation fails the function returns with an error code and themodule core invokes static_call_del_module() to clean up eventually addedstatic_call_mod entries.This works correctly, when all keys used by the module were converted overto a module chain before the failure. If not then static_call_del_module()causes a #GP as it blindly assumes that key::mods points to a valid structstatic_call_mod.The problem is that key::mods is not a individual struct member of structstatic_call_key, it s part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; };key::sites is a pointer to the list of built-in usage sites of the staticcall. The type of the pointer is differentiated by bit 0. A mods pointerhas the bit clear, the sites pointer has the bit set.As static_call_del_module() blidly assumes that the pointer is a validstatic_call_mod type, it fails to check for this failure case anddereferences the pointer to the list of built-in call sites, which isobviously bogus.Cure it by checking whether the key has a sites or a mods pointer.If it s a sites pointer then the key is not to be touched. As the sites arewalked in the same order as in __static_call_init() the site walk can beterminated because all subsequent sites have not been touched by the initcode due to the error exit.If it was converted before the allocation fail, then the inner loop whichsearches for a module match will find nothing.A fail in the second allocation in __static_call_init() is harmless anddoes not require special treatment. The first allocation succeeded andconverted the key to a module chain. That first entry has mod::mod == NULLand mod::next == NULL, so the inner loop of static_call_del_module() willneither find a module match nor a module chain. The next site in the walkwas either already converted, but can t match the module, or it will exitthe outer loop because it has a static_call_site pointer and not astatic_call_mod pointer.(CVE-2024-50002)\n\nIn the Linux kernel, the following vulnerability has been resolved:mac802154: Fix potential RCU dereference issue in mac802154_scan_workerIn the `mac802154_scan_worker` function, the `scan_req-\u0026gt;type` field wasaccessed after the RCU read-side critical section was unlocked. Accordingto RCU usage rules, this is illegal and can lead to unpredictablebehavior, such as accessing memory that has been updated or causinguse-after-free issues.This possible bug was identified using a static analysis tool developedby myself, specifically designed to detect RCU-related issues.To address this, the `scan_req-\u0026gt;type` value is now stored in a localvariable `scan_req_type` while still within the RCU read-side criticalsection. The `scan_req_type` is then used after the RCU lock is released,ensuring that the type value is safely accessed without violating RCUrules.(CVE-2024-50005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint\n\nPatch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.\n\nThis series fixes null pointer dereference bugs that occur when using\nnilfs2 and two block-related tracepoints.\n\n\nThis patch (of 2):\n\nIt has been reported that when using \u0026quot;block:block_touch_buffer\u0026quot;\ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a\nNULL pointer dereference, or a general protection fault when KASAN is\nenabled.\n\nThis happens because since the tracepoint was added in touch_buffer(), it\nreferences the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the\nbuffer head has a pointer to a block_device structure. In the current\nimplementation, the block_device structure is set after the function\nreturns to the caller.\n\nHere, touch_buffer() is used to mark the folio/page that owns the buffer\nhead as accessed, but the common search helper for folio/page used by the\ncaller function was optimized to mark the folio/page as accessed when it\nwas reimplemented a long time ago, eliminating the need to call\ntouch_buffer() here in the first place.\n\nSo this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm: adv7511: Fix use-after-free in adv7533_attach_dsi()The host_node pointer was assigned and freed in adv7533_parse_dt(), andlater, adv7533_attach_dsi() uses the same. Fix this use-after-free issueby\u00a0dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()in error path of probe() and also in the remove().(CVE-2024-57887)\n\nIn the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ( ila: call nf_unregister_net_hooks() sooner )attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: \u0026lt;IRQ\u0026gt; __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+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049(CVE-2024-57900)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before txBeginAnon() call\n\nAdded a read-only check before calling `txBeginAnon` in `extAlloc`\nand `extRecord`. This prevents modification attempts on a read-only\nmounted filesystem, avoiding potential errors or crashes.\n\nCall trace:\n txBeginAnon+0xac/0x154\n extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78\n jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248\n __block_write_begin_int+0x580/0x166c fs/buffer.c:2128\n __block_write_begin fs/buffer.c:2177 [inline]\n block_write_begin+0x98/0x11c fs/buffer.c:2236\n jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb2_lock\n\nIf smb_lock-\u0026gt;zero_len has value, -\u0026gt;llist of smb_lock is not delete and\nflock is old one. It will cause use-after-free on error handling\nroutine.(CVE-2025-21945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix slab-use-after-free on hdcp_work\n\n[Why]\nA slab-use-after-free is reported when HDCP is destroyed but the\nproperty_validate_dwork queue is still running.\n\n[How]\nCancel the delayed work when destroying workqueue.\n\n(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)(CVE-2025-21968)\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\nnfsd: put dl_stid if fail to queue dl_recall\n\nBefore calling nfsd4_run_cb to queue dl_recall to the callback_wq, we\nincrement the reference count of dl_stid.\nWe expect that after the corresponding work_struct is processed, the\nreference count of dl_stid will be decremented through the callback\nfunction nfsd4_cb_recall_release.\nHowever, if the call to nfsd4_run_cb fails, the incremented reference\ncount of dl_stid will not be decremented correspondingly, leading to the\nfollowing nfs4_stid leak:\nunreferenced object 0xffff88812067b578 (size 344):\n comm \u0026quot;nfsd\u0026quot;, pid 2761, jiffies 4295044002 (age 5541.241s)\n hex dump (first 32 bytes):\n 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........\n 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N..\n backtrace:\n kmem_cache_alloc+0x4b9/0x700\n nfsd4_process_open1+0x34/0x300\n nfsd4_open+0x2d1/0x9d0\n nfsd4_proc_compound+0x7a2/0xe30\n nfsd_dispatch+0x241/0x3e0\n svc_process_common+0x5d3/0xcc0\n svc_process+0x2a3/0x320\n nfsd+0x180/0x2e0\n kthread+0x199/0x1d0\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1b/0x30\nunreferenced object 0xffff8881499f4d28 (size 368):\n comm \u0026quot;nfsd\u0026quot;, pid 2761, jiffies 4295044005 (age 5541.239s)\n hex dump (first 32 bytes):\n 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I....\n 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... .......\n backtrace:\n kmem_cache_alloc+0x4b9/0x700\n nfs4_alloc_stid+0x29/0x210\n alloc_init_deleg+0x92/0x2e0\n nfs4_set_delegation+0x284/0xc00\n nfs4_open_delegation+0x216/0x3f0\n nfsd4_process_open2+0x2b3/0xee0\n nfsd4_open+0x770/0x9d0\n nfsd4_proc_compound+0x7a2/0xe30\n nfsd_dispatch+0x241/0x3e0\n svc_process_common+0x5d3/0xcc0\n svc_process+0x2a3/0x320\n nfsd+0x180/0x2e0\n kthread+0x199/0x1d0\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1b/0x30\nFix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if\nfail to queue dl_recall.(CVE-2025-22025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: don\u0026apos;t ignore the return code of svc_proc_register()\n\nCurrently, nfsd_proc_stat_init() ignores the return value of\nsvc_proc_register(). If the procfile creation fails, then the kernel\nwill WARN when it tries to remove the entry later.\n\nFix nfsd_proc_stat_init() to return the same type of pointer as\nsvc_proc_register(), and fix up nfsd_net_init() to check that and fail\nthe nfsd_net construction if it occurs.\n\nsvc_proc_register() can fail if the dentry can\u0026apos;t be allocated, or if an\nidentical dentry already exists. The second case is pretty unlikely in\nthe nfsd_net construction codepath, so if this happens, return -ENOMEM.(CVE-2025-22026)\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\nksmbd: add bounds check for create lease context\n\nAdd missing bounds check for create lease context.(CVE-2025-22042)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: add bounds check for durable handle context\n\nAdd missing bounds check for durable handle context.(CVE-2025-22043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: update channel list in reg notifier instead reg worker\n\nCurrently when ath11k gets a new channel list, it will be processed\naccording to the following steps:\n1. update new channel list to cfg80211 and queue reg_work.\n2. cfg80211 handles new channel list during reg_work.\n3. update cfg80211\u0026apos;s handled channel list to firmware by\nath11k_reg_update_chan_list().\n\nBut ath11k will immediately execute step 3 after reg_work is just\nqueued. Since step 2 is asynchronous, cfg80211 may not have completed\nhandling the new channel list, which may leading to an out-of-bounds\nwrite error:\nBUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list\nCall Trace:\n ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]\n kfree+0x109/0x3a0\n ath11k_regd_update+0x1cf/0x350 [ath11k]\n ath11k_regd_update_work+0x14/0x20 [ath11k]\n process_one_work+0xe35/0x14c0\n\nShould ensure step 2 is completely done before executing step 3. Thus\nWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,\ncfg80211 will notify ath11k after step 2 is done.\n\nSo enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will\nnotify ath11k after step 2 is done. At this time, there will be no\nKASAN bug during the execution of the step 3.\n\n[1] https://patchwork.kernel.org/project/linux-wireless/patch/(CVE-2025-23133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: uprobes: Add missing fence.i after building the XOL buffer\n\nThe XOL (execute out-of-line) buffer is used to single-step the\nreplaced instruction(s) for uprobes. The RISC-V port was missing a\nproper fence.i (i$ flushing) after constructing the XOL buffer, which\ncan result in incorrect execution of stale/broken instructions.\n\nThis was found running the BPF selftests \u0026quot;test_progs:\nuprobe_autoattach, attach_probe\u0026quot; on the Spacemit K1/X60, where the\nuprobes tests randomly blew up.(CVE-2025-37822)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue\n\nWhen the task management thread processes reply queues while the reset\nthread resets them, the task management thread accesses an invalid queue ID\n(0xFFFF), set by the reset thread, which points to unallocated memory,\ncausing a crash.\n\nAdd flag \u0026apos;io_admin_reset_sync\u0026apos; to synchronize access between the reset,\nI/O, and admin threads. Before a reset, the reset handler sets this flag to\nblock I/O and admin processing threads. If any thread bypasses the initial\ncheck, the reset thread waits up to 10 seconds for processing to finish. If\nthe wait exceeds 10 seconds, the controller is marked as unrecoverable.(CVE-2025-37861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in session logoff\n\nThe sess-\u0026gt;user object can currently be in use by another thread, for\nexample if another connection has sent a session setup request to\nbind to the session being free\u0026apos;d. The handler for that connection could\nbe in the smb2_sess_setup function which makes use of sess-\u0026gt;user.(CVE-2025-37899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation\n\nCurrently during the multi-link element defragmentation process, the\nmulti-link element length added to the total IEs length when calculating\nthe length of remaining IEs after the multi-link element in\ncfg80211_defrag_mle(). This could lead to out-of-bounds access if the\nmulti-link element or its corresponding fragment elements are the last\nelements in the IEs buffer.\n\nTo address this issue, correctly calculate the remaining IEs length by\ndeducting the multi-link element end offset from total IEs end offset.(CVE-2025-37973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix NULL pointer access\n\nThis patch ensures that the UCSI driver waits for all pending tasks in the\nucsi_displayport_work workqueue to finish executing before proceeding with\nthe partner removal.(CVE-2025-37994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: fix region locking in hash types\n\nRegion locking introduced in v5.6-rc4 contained three macros to handle\nthe region locks: ahash_bucket_start(), ahash_bucket_end() which gave\nback the start and end hash bucket values belonging to a given region\nlock and ahash_region() which should give back the region lock belonging\nto a given hash bucket. The latter was incorrect which can lead to a\nrace condition between the garbage collector and adding new elements\nwhen a hash type of set is defined with timeouts.(CVE-2025-37997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma: Add missing locking\n\nRecent kernels complain about a missing lock in k3-udma.c when the lock\nvalidator is enabled:\n\n[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238\n[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28\n[ 4.144867] Hardware name: pp-v12 (DT)\n[ 4.148648] Workqueue: events udma_check_tx_completion\n[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 4.160834] pc : udma_start.isra.0+0x34/0x238\n[ 4.165227] lr : udma_start.isra.0+0x30/0x238\n[ 4.169618] sp : ffffffc083cabcf0\n[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005\n[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000\n[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670\n[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030\n[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048\n[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001\n[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68\n[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8\n[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000\n[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000\n[ 4.244986] Call trace:\n[ 4.247463] udma_start.isra.0+0x34/0x238\n[ 4.251509] udma_check_tx_completion+0xd0/0xdc\n[ 4.256076] process_one_work+0x244/0x3fc\n[ 4.260129] process_scheduled_works+0x6c/0x74\n[ 4.264610] worker_thread+0x150/0x1dc\n[ 4.268398] kthread+0xd8/0xe8\n[ 4.271492] ret_from_fork+0x10/0x20\n[ 4.275107] irq event stamp: 220\n[ 4.278363] hardirqs last enabled at (219): [\u0026lt;ffffffc080a27c7c\u0026gt;] _raw_spin_unlock_irq+0x38/0x50\n[ 4.287183] hardirqs last disabled at (220): [\u0026lt;ffffffc080a1c154\u0026gt;] el1_dbg+0x24/0x50\n[ 4.294879] softirqs last enabled at (182): [\u0026lt;ffffffc080037e68\u0026gt;] handle_softirqs+0x1c0/0x3cc\n[ 4.303437] softirqs last disabled at (177): [\u0026lt;ffffffc080010170\u0026gt;] __do_softirq+0x1c/0x28\n[ 4.311559] ---[ end trace 0000000000000000 ]---\n\nThis commit adds the missing locking.(CVE-2025-38005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock\n\n... or we risk stealing final mntput from sync umount - raising mnt_count\nafter umount(2) has verified that victim is not busy, but before it\nhas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn\u0026apos;t see\nthat it\u0026apos;s safe to quietly undo mnt_count increment and leaves dropping\nthe reference to caller, where it\u0026apos;ll be a full-blown mntput().\n\nCheck under mount_lock is needed; leaving the current one done before\ntaking that makes no sense - it\u0026apos;s nowhere near common enough to bother\nwith.(CVE-2025-38058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Check return value from memblock_phys_alloc_range()\n\nAt least with CONFIG_PHYSICAL_START=0x100000, if there is \u0026lt; 4 MiB of\ncontiguous free memory available at this point, the kernel will crash\nand burn because memblock_phys_alloc_range() returns 0 on failure,\nwhich leads memblock_phys_free() to throw the first 4 MiB of physical\nmemory to the wolves.\n\nAt a minimum it should fail gracefully with a meaningful diagnostic,\nbut in fact everything seems to work fine without the weird reserve\nallocation.(CVE-2025-38071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix ECVF vports unload on shutdown flow\n\nFix shutdown flow UAF when a virtual function is created on the embedded\nchip (ECVF) of a BlueField device. In such case the vport acl ingress\ntable is not properly destroyed.\n\nECVF functionality is independent of ecpf_vport_exists capability and\nthus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not\ntest it when enabling/disabling ECVF vports.\n\nkernel log:\n[] refcount_t: underflow; use-after-free.\n[] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28\n refcount_warn_saturate+0x124/0x220\n----------------\n[] Call trace:\n[] refcount_warn_saturate+0x124/0x220\n[] tree_put_node+0x164/0x1e0 [mlx5_core]\n[] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core]\n[] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core]\n[] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core]\n[] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core]\n[] esw_vport_cleanup+0x64/0x90 [mlx5_core]\n[] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core]\n[] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core]\n[] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core]\n[] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core]\n[] mlx5_sriov_detach+0x40/0x50 [mlx5_core]\n[] mlx5_unload+0x40/0xc4 [mlx5_core]\n[] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core]\n[] mlx5_unload_one+0x3c/0x60 [mlx5_core]\n[] shutdown+0x7c/0xa4 [mlx5_core]\n[] pci_device_shutdown+0x3c/0xa0\n[] device_shutdown+0x170/0x340\n[] __do_sys_reboot+0x1f4/0x2a0\n[] __arm64_sys_reboot+0x2c/0x40\n[] invoke_syscall+0x78/0x100\n[] el0_svc_common.constprop.0+0x54/0x184\n[] do_el0_svc+0x30/0xac\n[] el0_svc+0x48/0x160\n[] el0t_64_sync_handler+0xa4/0x12c\n[] el0t_64_sync+0x1a4/0x1a8\n[] --[ end trace 9c4601d68c70030e ]---(CVE-2025-38109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: Initialize ssc before laundromat_work to prevent NULL dereference\n\nIn nfs4_state_start_net(), laundromat_work may access nfsd_ssc through\nnfs4_laundromat -\u0026gt; nfsd4_ssc_expire_umount. If nfsd_ssc isn\u0026apos;t initialized,\nthis can cause NULL pointer dereference.\n\nNormally the delayed start of laundromat_work allows sufficient time for\nnfsd_ssc initialization to complete. However, when the kernel waits too\nlong for userspace responses (e.g. in nfs4_state_start_net -\u0026gt;\nnfsd4_end_grace -\u0026gt; nfsd4_record_grace_done -\u0026gt; nfsd4_cld_grace_done -\u0026gt;\ncld_pipe_upcall -\u0026gt; __cld_pipe_upcall -\u0026gt; wait_for_completion path), the\ndelayed work may start before nfsd_ssc initialization finishes.\n\nFix this by moving nfsd_ssc initialization before starting laundromat_work.(CVE-2025-38231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkernfs: Relax constraint in draining guard\n\nThe active reference lifecycle provides the break/unbreak mechanism but\nthe active reference is not truly active after unbreak -- callers don\u0026apos;t\nuse it afterwards but it\u0026apos;s important for proper pairing of kn-\u0026gt;active\ncounting. Assuming this mechanism is in place, the WARN check in\nkernfs_should_drain_open_files() is too sensitive -- it may transiently\ncatch those (rightful) callers between\nkernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen\nRidong:\n\n\tkernfs_remove_by_name_ns\tkernfs_get_active // active=1\n\t__kernfs_remove\t\t\t\t\t // active=0x80000002\n\tkernfs_drain\t\t\t...\n\twait_event\n\t//waiting (active == 0x80000001)\n\t\t\t\t\tkernfs_break_active_protection\n\t\t\t\t\t// active = 0x80000001\n\t// continue\n\t\t\t\t\tkernfs_unbreak_active_protection\n\t\t\t\t\t// active = 0x80000002\n\t...\n\tkernfs_should_drain_open_files\n\t// warning occurs\n\t\t\t\t\tkernfs_put_active\n\nTo avoid the false positives (mind panic_on_warn) remove the check altogether.\n(This is meant as quick fix, I think active reference break/unbreak may be\nsimplified with larger rework.)(CVE-2025-38282)\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\ndrm/amd/display: Check dce_hwseq before dereferencing it\n\n[WHAT]\n\nhws was checked for null earlier in dce110_blank_stream, indicating hws\ncan be null, and should be checked whenever it is used.\n\n(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)(CVE-2025-38361)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix uaf in nbd_genl_connect() error path\n\nThere is a use-after-free issue in nbd:\n\nblock nbd6: Receive control failed (result -104)\nblock nbd6: shutting down sockets\n==================================================================\nBUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022\nWrite of size 4 at addr ffff8880295de478 by task kworker/u33:0/67\n\nCPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #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\nWorkqueue: nbd6-recv recv_work\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:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n instrument_atomic_read_write include/linux/instrumented.h:96 [inline]\n atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline]\n recv_work+0x694/0xa80 drivers/block/nbd.c:1022\n process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n process_scheduled_works kernel/workqueue.c:3319 [inline]\n worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n kthread+0x3c2/0x780 kernel/kthread.c:464\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;\n\nnbd_genl_connect() does not properly stop the device on certain\nerror paths after nbd_start_device() has been called. This causes\nthe error path to put nbd-\u0026gt;config while recv_work continue to use\nthe config after putting it, leading to use-after-free in recv_work.\n\nThis patch moves nbd_start_device() after the backend file creation.(CVE-2025-38443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Abort __tc_modify_qdisc if parent class does not exist\n\nLion\u0026apos;s patch [1] revealed an ancient bug in the qdisc API.\nWhenever a user creates/modifies a qdisc specifying as a parent another\nqdisc, the qdisc API will, during grafting, detect that the user is\nnot trying to attach to a class and reject. However grafting is\nperformed after qdisc_create (and thus the qdiscs\u0026apos; init callback) is\nexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlog\nduring init or change (such as fq, hhf, choke, etc), an issue\narises. For example, executing the following commands:\n\nsudo tc qdisc add dev lo root handle a: htb default 2\nsudo tc qdisc add dev lo parent a: handle beef fq\n\nQdiscs such as fq, hhf, choke, etc unconditionally invoke\nqdisc_tree_reduce_backlog() in their control path init() or change() which\nthen causes a failure to find the child class; however, that does not stop\nthe unconditional invocation of the assumed child qdisc\u0026apos;s qlen_notify with\na null class. All these qdiscs make the assumption that class is non-null.\n\nThe solution is ensure that qdisc_leaf() which looks up the parent\nclass, and is invoked prior to qdisc_create(), should return failure on\nnot finding the class.\nIn this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the\nparentid doesn\u0026apos;t correspond to a class, so that we can detect it\nearlier on and abort before qdisc_create is called.\n\n[1] https://lore.kernel.org/netdev/(CVE-2025-38457)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime\n\nAssuming the \u0026quot;rx-vlan-filter\u0026quot; feature is enabled on a net device, the\n8021q module will automatically add or remove VLAN 0 when the net device\nis put administratively up or down, respectively. There are a couple of\nproblems with the above scheme.\n\nThe first problem is a memory leak that can happen if the \u0026quot;rx-vlan-filter\u0026quot;\nfeature is disabled while the device is running:\n\n # ip link add bond1 up type bond mode 0\n # ethtool -K bond1 rx-vlan-filter off\n # ip link del dev bond1\n\nWhen the device is put administratively down the \u0026quot;rx-vlan-filter\u0026quot;\nfeature is disabled, so the 8021q module will not remove VLAN 0 and the\nmemory will be leaked [1].\n\nAnother problem that can happen is that the kernel can automatically\ndelete VLAN 0 when the device is put administratively down despite not\nadding it when the device was put administratively up since during that\ntime the \u0026quot;rx-vlan-filter\u0026quot; feature was disabled. null-ptr-unref or\nbug_on[2] will be triggered by unregister_vlan_dev() for refcount\nimbalance if toggling filtering during runtime:\n\n$ ip link add bond0 type bond mode 0\n$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q\n$ ethtool -K bond0 rx-vlan-filter off\n$ ifconfig bond0 up\n$ ethtool -K bond0 rx-vlan-filter on\n$ ifconfig bond0 down\n$ ip link del vlan0\n\nRoot cause is as below:\nstep1: add vlan0 for real_dev, such as bond, team.\nregister_vlan_dev\n vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1\nstep2: disable vlan filter feature and enable real_dev\nstep3: change filter from 0 to 1\nvlan_device_event\n vlan_filter_push_vids\n ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0\nstep4: real_dev down\nvlan_device_event\n vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0\n vlan_info_rcu_free //free vlan0\nstep5: delete vlan0\nunregister_vlan_dev\n BUG_ON(!vlan_info); //vlan_info is null\n\nFix both problems by noting in the VLAN info whether VLAN 0 was\nautomatically added upon NETDEV_UP and based on that decide whether it\nshould be deleted upon NETDEV_DOWN, regardless of the state of the\n\u0026quot;rx-vlan-filter\u0026quot; feature.\n\n[1]\nunreferenced object 0xffff8880068e3100 (size 256):\n comm \u0026quot;ip\u0026quot;, pid 384, jiffies 4296130254\n hex dump (first 32 bytes):\n 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0.............\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 81ce31fa):\n __kmalloc_cache_noprof+0x2b5/0x340\n vlan_vid_add+0x434/0x940\n vlan_device_event.cold+0x75/0xa8\n notifier_call_chain+0xca/0x150\n __dev_notify_flags+0xe3/0x250\n rtnl_configure_link+0x193/0x260\n rtnl_newlink_create+0x383/0x8e0\n __rtnl_newlink+0x22c/0xa40\n rtnl_newlink+0x627/0xb00\n rtnetlink_rcv_msg+0x6fb/0xb70\n netlink_rcv_skb+0x11f/0x350\n netlink_unicast+0x426/0x710\n netlink_sendmsg+0x75a/0xc20\n __sock_sendmsg+0xc1/0x150\n ____sys_sendmsg+0x5aa/0x7b0\n ___sys_sendmsg+0xfc/0x180\n\n[2]\nkernel BUG at net/8021q/vlan.c:99!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))\nRSP: 0018:ffff88810badf310 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8\nRBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80\nR10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000\nR13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e\nFS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\n---truncated---(CVE-2025-38470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix race condition on qfq_aggregate\n\nA race condition can occur when \u0026apos;agg\u0026apos; is modified in qfq_change_agg\n(called during qfq_enqueue) while other threads access it\nconcurrently. For example, qfq_dump_class may trigger a NULL\ndereference, and qfq_delete_class may cause a use-after-free.\n\nThis patch addresses the issue by:\n\n1. Moved qfq_destroy_class into the critical section.\n\n2. Added sch_tree_lock protection to qfq_dump_class and\nqfq_dump_class_stats.(CVE-2025-38477)\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\nsunrpc: fix handling of server side tls alerts\n\nScott Mayhew discovered a security exploit in NFS over TLS in\ntls_alert_recv() due to its assumption it can read data from\nthe msg iterator\u0026apos;s kvec..\n\nkTLS implementation splits TLS non-data record payload between\nthe control message buffer (which includes the type such as TLS\naler or TLS cipher change) and the rest of the payload (say TLS\nalert\u0026apos;s level/description) which goes into the msg payload buffer.\n\nThis patch proposes to rework how control messages are setup and\nused by sock_recvmsg().\n\nIf no control message structure is setup, kTLS layer will read and\nprocess TLS data record types. As soon as it encounters a TLS control\nmessage, it would return an error. At that point, NFS can setup a\nkvec backed msg buffer and read in the control message such as a\nTLS alert. Msg iterator can advance the kvec pointer as a part of\nthe copy process thus we need to revert the iterator before calling\ninto the tls_alert_recv.(CVE-2025-38566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent infinite loop in rt6_nlmsg_size()\n\nWhile testing prior patch, I was able to trigger\nan infinite loop in rt6_nlmsg_size() in the following place:\n\nlist_for_each_entry_rcu(sibling, \u0026amp;f6i-\u0026gt;fib6_siblings,\n\t\t\tfib6_siblings) {\n\trt6_nh_nlmsg_size(sibling-\u0026gt;fib6_nh, \u0026amp;nexthop_len);\n}\n\nThis is because fib6_del_route() and fib6_add_rt2node()\nuses list_del_rcu(), which can confuse rcu readers,\nbecause they might no longer see the head of the list.\n\nRestart the loop if f6i-\u0026gt;fib6_nsiblings is zero.(CVE-2025-38588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: Fix semi-unbounded recursion\n\nEnsure that epoll instances can never form a graph deeper than\nEP_MAX_NESTS+1 links.\n\nCurrently, ep_loop_check_proc() ensures that the graph is loop-free and\ndoes some recursion depth checks, but those recursion depth checks don\u0026apos;t\nlimit the depth of the resulting tree for two reasons:\n\n - They don\u0026apos;t look upwards in the tree.\n - If there are multiple downwards paths of different lengths, only one of\n the paths is actually considered for the depth check since commit\n 28d82dc1c4ed (\u0026quot;epoll: limit paths\u0026quot;).\n\nEssentially, the current recursion depth check in ep_loop_check_proc() just\nserves to prevent it from recursing too deeply while checking for loops.\n\nA more thorough check is done in reverse_path_check() after the new graph\nedge has already been created; this checks, among other things, that no\npaths going upwards from any non-epoll file with a length of more than 5\nedges exist. However, this check does not apply to non-epoll files.\n\nAs a result, it is possible to recurse to a depth of at least roughly 500,\ntested on v6.15. (I am unsure if deeper recursion is possible; and this may\nhave changed with commit 8c44dac8add7 (\u0026quot;eventpoll: Fix priority inversion\nproblem\u0026quot;).)\n\nTo fix it:\n\n1. In ep_loop_check_proc(), note the subtree depth of each visited node,\nand use subtree depths for the total depth calculation even when a subtree\nhas already been visited.\n2. Add ep_get_upwards_depth_proc() for similarly determining the maximum\ndepth of an upwards walk.\n3. In ep_loop_check(), use these values to limit the total path length\nbetween epoll nodes to EP_MAX_NESTS edges.(CVE-2025-38614)\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\nrv: Use strings in da monitors tracepoints\n\nUsing DA monitors tracepoints with KASAN enabled triggers the following\nwarning:\n\n BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0\n Read of size 32 at addr ffffffffaada8980 by task ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n [...]\n do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0\n ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10\n ? trace_event_sncid+0x83/0x200\n trace_event_sncid+0x163/0x200\n [...]\n The buggy address belongs to the variable:\n automaton_snep+0x4e0/0x5e0\n\nThis is caused by the tracepoints reading 32 bytes __array instead of\n__string from the automata definition. Such strings are literals and\nreading 32 bytes ends up in out of bound memory accesses (e.g. the next\nautomaton\u0026apos;s data in this case).\nThe error is harmless as, while printing the string, we stop at the null\nterminator, but it should still be fixed.\n\nUse the __string facilities while defining the tracepoints to avoid\nreading out of bound memory.(CVE-2025-38636)\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\nnetlink: avoid infinite retry looping in netlink_unicast()\n\nnetlink_attachskb() checks for the socket\u0026apos;s read memory allocation\nconstraints. Firstly, it has:\n\n rmem \u0026lt; READ_ONCE(sk-\u0026gt;sk_rcvbuf)\n\nto check if the just increased rmem value fits into the socket\u0026apos;s receive\nbuffer. If not, it proceeds and tries to wait for the memory under:\n\n rmem + skb-\u0026gt;truesize \u0026gt; READ_ONCE(sk-\u0026gt;sk_rcvbuf)\n\nThe checks don\u0026apos;t cover the case when skb-\u0026gt;truesize + sk-\u0026gt;sk_rmem_alloc is\nequal to sk-\u0026gt;sk_rcvbuf. Thus the function neither successfully accepts\nthese conditions, nor manages to reschedule the task - and is called in\nretry loop for indefinite time which is caught as:\n\n rcu: INFO: rcu_sched self-detected stall on CPU\n rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212\n (t=26000 jiffies g=230833 q=259957)\n NMI backtrace for cpu 0\n CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack lib/dump_stack.c:120\n nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105\n nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62\n rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335\n rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590\n update_process_times kernel/time/timer.c:1953\n tick_sched_handle kernel/time/tick-sched.c:227\n tick_sched_timer kernel/time/tick-sched.c:1399\n __hrtimer_run_queues kernel/time/hrtimer.c:1652\n hrtimer_interrupt kernel/time/hrtimer.c:1717\n __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113\n asm_call_irq_on_stack arch/x86/entry/entry_64.S:808\n \u0026lt;/IRQ\u0026gt;\n\n netlink_attachskb net/netlink/af_netlink.c:1234\n netlink_unicast net/netlink/af_netlink.c:1349\n kauditd_send_queue kernel/audit.c:776\n kauditd_thread kernel/audit.c:897\n kthread kernel/kthread.c:328\n ret_from_fork arch/x86/entry/entry_64.S:304\n\nRestore the original behavior of the check which commit in Fixes\naccidentally missed when restructuring the code.\n\nFound by Linux Verification Center (linuxtesting.org).(CVE-2025-38727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()\n\nThe function mod_hdcp_hdcp1_create_session() calls the function\nget_first_active_display(), but does not check its return value.\nThe return value is a null pointer if the display list is empty.\nThis will lead to a null pointer dereference.\n\nAdd a null pointer check for get_first_active_display() and return\nMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.\n\nThis is similar to the commit c3e9826a2202\n(\u0026quot;drm/amd/display: Add null pointer check for get_first_active_display()\u0026quot;).\n\n(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)(CVE-2025-39675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Fix backlog accounting in qdisc_dequeue_internal\n\nThis issue applies for the following qdiscs: hhf, fq, fq_codel, and\nfq_pie, and occurs in their change handlers when adjusting to the new\nlimit. The problem is the following in the values passed to the\nsubsequent qdisc_tree_reduce_backlog call given a tbf parent:\n\n When the tbf parent runs out of tokens, skbs of these qdiscs will\n be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,\n which accounts for both qlen and backlog. However, in the case of\n qdisc_dequeue_internal, ONLY qlen is accounted for when pulling\n from gso_skb. This means that these qdiscs are missing a\n qdisc_qstats_backlog_dec when dropping packets to satisfy the\n new limit in their change handlers.\n\n One can observe this issue with the following (with tc patched to\n support a limit of 0):\n\n export TARGET=fq\n tc qdisc del dev lo root\n tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms\n tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000\n echo \u0026apos;\u0026apos;; echo \u0026apos;add child\u0026apos;; tc -s -d qdisc show dev lo\n ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2\u0026gt;\u0026amp;1 \u0026gt;/dev/null\n echo \u0026apos;\u0026apos;; echo \u0026apos;after ping\u0026apos;; tc -s -d qdisc show dev lo\n tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0\n echo \u0026apos;\u0026apos;; echo \u0026apos;after limit drop\u0026apos;; tc -s -d qdisc show dev lo\n tc qdisc replace dev lo handle 2: parent 1:1 sfq\n echo \u0026apos;\u0026apos;; echo \u0026apos;post graft\u0026apos;; tc -s -d qdisc show dev lo\n\n The second to last show command shows 0 packets but a positive\n number (74) of backlog bytes. The problem becomes clearer in the\n last show command, where qdisc_purge_queue triggers\n qdisc_tree_reduce_backlog with the positive backlog and causes an\n underflow in the tbf parent\u0026apos;s backlog (4096 Mb instead of 0).\n\nTo fix this issue, the codepath for all clients of qdisc_dequeue_internal\nhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.\nqdisc_dequeue_internal handles the backlog adjustments for all cases that\ndo not directly use the dequeue handler.\n\nThe old fq_codel_change limit adjustment loop accumulated the arguments to\nthe subsequent qdisc_tree_reduce_backlog call through the cstats field.\nHowever, this is confusing and error prone as fq_codel_dequeue could also\npotentially mutate this field (which qdisc_dequeue_internal calls in the\nnon gso_skb case), so we have unified the code here with other qdiscs.(CVE-2025-39677)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()\n\nsyzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernel\nbuffer is allocated to hold `insn-\u0026gt;n` samples (each of which is an\n`unsigned int`). For some instruction types, `insn-\u0026gt;n` samples are\ncopied back to user-space, unless an error code is being returned. The\nproblem is that not all the instruction handlers that need to return\ndata to userspace fill in the whole `insn-\u0026gt;n` samples, so that there is\nan information leak. There is a similar syzbot report for\n`do_insnlist_ioctl()`, although it does not have a reproducer for it at\nthe time of writing.\n\nOne culprit is `insn_rw_emulate_bits()` which is used as the handler for\n`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have\na specific handler for that instruction, but do have an `INSN_BITS`\nhandler. For `INSN_READ` it only fills in at most 1 sample, so if\n`insn-\u0026gt;n` is greater than 1, the remaining `insn-\u0026gt;n - 1` samples copied\nto userspace will be uninitialized kernel data.\n\nAnother culprit is `vm80xx_ai_insn_read()` in the \u0026quot;vm80xx\u0026quot; driver. It\nnever returns an error, even if it fails to fill the buffer.\n\nFix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure\nthat uninitialized parts of the allocated buffer are zeroed before\nhandling each instruction.\n\nThanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fix\nreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is not\nalways necessary to clear the whole buffer.(CVE-2025-39684)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a race when updating an existing write\n\nAfter nfs_lock_and_join_requests() tests for whether the request is\nstill attached to the mapping, nothing prevents a call to\nnfs_inode_remove_request() from succeeding until we actually lock the\npage group.\nThe reason is that whoever called nfs_inode_remove_request() doesn\u0026apos;t\nnecessarily have a lock on the page group head.\n\nSo in order to avoid races, let\u0026apos;s take the page group lock earlier in\nnfs_lock_and_join_requests(), and hold it across the removal of the\nrequest in nfs_inode_remove_request().(CVE-2025-39697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix memory corruption when FW resources change during ifdown\n\nbnxt_set_dflt_rings() assumes that it is always called before any TC has\nbeen created. So it doesn\u0026apos;t take bp-\u0026gt;num_tc into account and assumes\nthat it is always 0 or 1.\n\nIn the FW resource or capability change scenario, the FW will return\nflags in bnxt_hwrm_if_change() that will cause the driver to\nreinitialize and call bnxt_cancel_reservations(). This will lead to\nbnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp-\u0026gt;num_tc\nmay be greater than 1. This will cause bp-\u0026gt;tx_ring[] to be sized too\nsmall and cause memory corruption in bnxt_alloc_cp_rings().\n\nFix it by properly scaling the TX rings by bp-\u0026gt;num_tc in the code\npaths mentioned above. Add 2 helper functions to determine\nbp-\u0026gt;tx_nr_rings and bp-\u0026gt;tx_nr_rings_per_tc.(CVE-2025-39810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: Fix slab-out-of-bounds in efivarfs_d_compare\n\nObserved on kernel 6.6 (present on master as well):\n\n BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0\n Call trace:\n kasan_check_range+0xe8/0x190\n __asan_loadN+0x1c/0x28\n memcmp+0x98/0xd0\n efivarfs_d_compare+0x68/0xd8\n __d_lookup_rcu_op_compare+0x178/0x218\n __d_lookup_rcu+0x1f8/0x228\n d_alloc_parallel+0x150/0x648\n lookup_open.isra.0+0x5f0/0x8d0\n open_last_lookups+0x264/0x828\n path_openat+0x130/0x3f8\n do_filp_open+0x114/0x248\n do_sys_openat2+0x340/0x3c0\n __arm64_sys_openat+0x120/0x1a0\n\nIf dentry-\u0026gt;d_name.len \u0026lt; EFI_VARIABLE_GUID_LEN , \u0026apos;guid\u0026apos; can become\nnegative, leadings to oob. The issue can be triggered by parallel\nlookups using invalid filename:\n\n T1\t\t\tT2\n lookup_open\n -\u0026gt;lookup\n simple_lookup\n d_add\n // invalid dentry is added to hash list\n\n\t\t\tlookup_open\n\t\t\t d_alloc_parallel\n\t\t\t __d_lookup_rcu\n\t\t\t __d_lookup_rcu_op_compare\n\t\t\t hlist_bl_for_each_entry_rcu\n\t\t\t // invalid dentry can be retrieved\n\t\t\t -\u0026gt;d_compare\n\t\t\t efivarfs_d_compare\n\t\t\t // oob\n\nFix it by checking \u0026apos;guid\u0026apos; before cmp.(CVE-2025-39817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix race with concurrent opens in rename(2)\n\nBesides sending the rename request to the server, the rename process\nalso involves closing any deferred close, waiting for outstanding I/O\nto complete as well as marking all existing open handles as deleted to\nprevent them from deferring closes, which increases the race window\nfor potential concurrent opens on the target file.\n\nFix this by unhashing the dentry in advance to prevent any concurrent\nopens on the target.(CVE-2025-39825)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: writeback: fix use-after-free in __mark_inode_dirty()\n\nAn use-after-free issue occurred when __mark_inode_dirty() get the\nbdi_writeback that was in the progress of switching.\n\nCPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1\n......\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __mark_inode_dirty+0x124/0x418\nlr : __mark_inode_dirty+0x118/0x418\nsp : ffffffc08c9dbbc0\n........\nCall trace:\n __mark_inode_dirty+0x124/0x418\n generic_update_time+0x4c/0x60\n file_modified+0xcc/0xd0\n ext4_buffered_write_iter+0x58/0x124\n ext4_file_write_iter+0x54/0x704\n vfs_write+0x1c0/0x308\n ksys_write+0x74/0x10c\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x114\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x40/0xe4\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x194/0x198\n\nRoot cause is:\n\nsystemd-random-seed kworker\n----------------------------------------------------------------------\n___mark_inode_dirty inode_switch_wbs_work_fn\n\n spin_lock(\u0026amp;inode-\u0026gt;i_lock);\n inode_attach_wb\n locked_inode_to_wb_and_lock_list\n get inode-\u0026gt;i_wb\n spin_unlock(\u0026amp;inode-\u0026gt;i_lock);\n spin_lock(\u0026amp;wb-\u0026gt;list_lock)\n spin_lock(\u0026amp;inode-\u0026gt;i_lock)\n inode_io_list_move_locked\n spin_unlock(\u0026amp;wb-\u0026gt;list_lock)\n spin_unlock(\u0026amp;inode-\u0026gt;i_lock)\n spin_lock(\u0026amp;old_wb-\u0026gt;list_lock)\n inode_do_switch_wbs\n spin_lock(\u0026amp;inode-\u0026gt;i_lock)\n inode-\u0026gt;i_wb = new_wb\n spin_unlock(\u0026amp;inode-\u0026gt;i_lock)\n spin_unlock(\u0026amp;old_wb-\u0026gt;list_lock)\n wb_put_many(old_wb, nr_switched)\n cgwb_release\n old wb released\n wb_wakeup_delayed() accesses wb,\n then trigger the use-after-free\n issue\n\nFix this race condition by holding inode spinlock until\nwb_wakeup_delayed() finished.(CVE-2025-39866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkernfs: Fix UAF in polling when open file is released\n\nA use-after-free (UAF) vulnerability was identified in the PSI (Pressure\nStall Information) monitoring mechanism:\n\nBUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140\nRead of size 8 at addr ffff3de3d50bd308 by task systemd/1\n\npsi_trigger_poll+0x3c/0x140\ncgroup_pressure_poll+0x70/0xa0\ncgroup_file_poll+0x8c/0x100\nkernfs_fop_poll+0x11c/0x1c0\nep_item_poll.isra.0+0x188/0x2c0\n\nAllocated by task 1:\ncgroup_file_open+0x88/0x388\nkernfs_fop_open+0x73c/0xaf0\ndo_dentry_open+0x5fc/0x1200\nvfs_open+0xa0/0x3f0\ndo_open+0x7e8/0xd08\npath_openat+0x2fc/0x6b0\ndo_filp_open+0x174/0x368\n\nFreed by task 8462:\ncgroup_file_release+0x130/0x1f8\nkernfs_drain_open_files+0x17c/0x440\nkernfs_drain+0x2dc/0x360\nkernfs_show+0x1b8/0x288\ncgroup_file_show+0x150/0x268\ncgroup_pressure_write+0x1dc/0x340\ncgroup_file_write+0x274/0x548\n\nReproduction Steps:\n1. Open test/cpu.pressure and establish epoll monitoring\n2. Disable monitoring: echo 0 \u0026gt; test/cgroup.pressure\n3. Re-enable monitoring: echo 1 \u0026gt; test/cgroup.pressure\n\nThe race condition occurs because:\n1. When cgroup.pressure is disabled (echo 0 \u0026gt; cgroup.pressure), it:\n - Releases PSI triggers via cgroup_file_release()\n - Frees of-\u0026gt;priv through kernfs_drain_open_files()\n2. While epoll still holds reference to the file and continues polling\n3. Re-enabling (echo 1 \u0026gt; cgroup.pressure) accesses freed of-\u0026gt;priv\n\nepolling\t\t\tdisable/enable cgroup.pressure\nfd=open(cpu.pressure)\nwhile(1)\n...\nepoll_wait\nkernfs_fop_poll\nkernfs_get_active = true\techo 0 \u0026gt; cgroup.pressure\n...\t\t\t\tcgroup_file_show\n\t\t\t\tkernfs_show\n\t\t\t\t// inactive kn\n\t\t\t\tkernfs_drain_open_files\n\t\t\t\tcft-\u0026gt;release(of);\n\t\t\t\tkfree(ctx);\n\t\t\t\t...\nkernfs_get_active = false\n\t\t\t\techo 1 \u0026gt; cgroup.pressure\n\t\t\t\tkernfs_show\n\t\t\t\tkernfs_activate_one(kn);\nkernfs_fop_poll\nkernfs_get_active = true\ncgroup_file_poll\npsi_trigger_poll\n// UAF\n...\nend: close(fd)\n\nTo address this issue, introduce kernfs_get_active_of() for kernfs open\nfiles to obtain active references. This function will fail if the open file\nhas been released. Replace kernfs_get_active() with kernfs_get_active_of()\nto prevent further operations on released file descriptors.(CVE-2025-39881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path\n\nIf request_irq() in i40e_vsi_request_irq_msix() fails in an iteration\nlater than the first, the error path wants to free the IRQs requested\nso far. However, it uses the wrong dev_id argument for free_irq(), so\nit does not free the IRQs correctly and instead triggers the warning:\n\n Trying to free already-free IRQ 173\n WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0\n Modules linked in: i40e(+) [...]\n CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)\n Hardware name: [...]\n RIP: 0010:__free_irq+0x192/0x2c0\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n free_irq+0x32/0x70\n i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]\n i40e_vsi_request_irq+0x79/0x80 [i40e]\n i40e_vsi_open+0x21f/0x2f0 [i40e]\n i40e_open+0x63/0x130 [i40e]\n __dev_open+0xfc/0x210\n __dev_change_flags+0x1fc/0x240\n netif_change_flags+0x27/0x70\n do_setlink.isra.0+0x341/0xc70\n rtnl_newlink+0x468/0x860\n rtnetlink_rcv_msg+0x375/0x450\n netlink_rcv_skb+0x5c/0x110\n netlink_unicast+0x288/0x3c0\n netlink_sendmsg+0x20d/0x430\n ____sys_sendmsg+0x3a2/0x3d0\n ___sys_sendmsg+0x99/0xe0\n __sys_sendmsg+0x8a/0xf0\n do_syscall_64+0x82/0x2c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nUse the same dev_id for free_irq() as for request_irq().\n\nI tested this with inserting code to fail intentionally.(CVE-2025-39911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Harden uplink netdev access against device unbind\n\nThe function mlx5_uplink_netdev_get() gets the uplink netdevice\npointer from mdev-\u0026gt;mlx5e_res.uplink_netdev. However, the netdevice can\nbe removed and its pointer cleared when unbound from the mlx5_core.eth\ndriver. This results in a NULL pointer, causing a kernel panic.\n\n BUG: unable to handle page fault for address: 0000000000001300\n at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]\n esw_offloads_enable+0x593/0x910 [mlx5_core]\n mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]\n mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]\n devlink_nl_eswitch_set_doit+0x60/0xd0\n genl_family_rcv_msg_doit+0xe0/0x130\n genl_rcv_msg+0x183/0x290\n netlink_rcv_skb+0x4b/0xf0\n genl_rcv+0x24/0x40\n netlink_unicast+0x255/0x380\n netlink_sendmsg+0x1f3/0x420\n __sock_sendmsg+0x38/0x60\n __sys_sendto+0x119/0x180\n do_syscall_64+0x53/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nEnsure the pointer is valid before use by checking it for NULL. If it\nis valid, immediately call netdev_hold() to take a reference, and\npreventing the netdevice from being freed while it is in use.(CVE-2025-39947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: tuner: xc5000: Fix use-after-free in xc5000_release\n\nThe original code uses cancel_delayed_work() in xc5000_release(), which\ndoes not guarantee that the delayed work item timer_sleep has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere xc5000_release() may free the xc5000_priv while timer_sleep is still\nactive and attempts to dereference the xc5000_priv.\n\nA typical race condition is illustrated below:\n\nCPU 0 (release thread) | CPU 1 (delayed work callback)\nxc5000_release() | xc5000_do_timer_sleep()\n cancel_delayed_work() |\n hybrid_tuner_release_state(priv) |\n kfree(priv) |\n | priv = container_of() // UAF\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the timer_sleep is properly canceled before the xc5000_priv memory\nis deallocated.\n\nA deadlock concern was considered: xc5000_release() is called in a process\ncontext and is not holding any locks that the timer_sleep work item might\nalso need. Therefore, the use of the _sync() variant is safe here.\n\nThis bug was initially identified through static analysis.\n\n[hverkuil: fix typo in Subject: tunner -\u0026gt; tuner](CVE-2025-39994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove\n\nThe original code uses cancel_delayed_work() in flexcop_pci_remove(), which\ndoes not guarantee that the delayed work item irq_check_work has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere flexcop_pci_remove() may free the flexcop_device while irq_check_work\nis still active and attempts to dereference the device.\n\nA typical race condition is illustrated below:\n\nCPU 0 (remove) | CPU 1 (delayed work callback)\nflexcop_pci_remove() | flexcop_pci_irq_check_work()\n cancel_delayed_work() |\n flexcop_device_kfree(fc_pci-\u0026gt;fc_dev) |\n | fc = fc_pci-\u0026gt;fc_dev; // UAF\n\nThis is confirmed by a KASAN report:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0\nWrite of size 8 at addr ffff8880093aa8c8 by task bash/135\n...\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x55/0x70\n print_report+0xcf/0x610\n ? __run_timer_base.part.0+0x7d7/0x8c0\n kasan_report+0xb8/0xf0\n ? __run_timer_base.part.0+0x7d7/0x8c0\n __run_timer_base.part.0+0x7d7/0x8c0\n ? __pfx___run_timer_base.part.0+0x10/0x10\n ? __pfx_read_tsc+0x10/0x10\n ? ktime_get+0x60/0x140\n ? lapic_next_event+0x11/0x20\n ? clockevents_program_event+0x1d4/0x2a0\n run_timer_softirq+0xd1/0x190\n handle_softirqs+0x16a/0x550\n irq_exit_rcu+0xaf/0xe0\n sysvec_apic_timer_interrupt+0x70/0x80\n \u0026lt;/IRQ\u0026gt;\n...\n\nAllocated by task 1:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x1be/0x460\n flexcop_device_kmalloc+0x54/0xe0\n flexcop_pci_probe+0x1f/0x9d0\n local_pci_probe+0xdc/0x190\n pci_device_probe+0x2fe/0x470\n really_probe+0x1ca/0x5c0\n __driver_probe_device+0x248/0x310\n driver_probe_device+0x44/0x120\n __driver_attach+0xd2/0x310\n bus_for_each_dev+0xed/0x170\n bus_add_driver+0x208/0x500\n driver_register+0x132/0x460\n do_one_initcall+0x89/0x300\n kernel_init_freeable+0x40d/0x720\n kernel_init+0x1a/0x150\n ret_from_fork+0x10c/0x1a0\n ret_from_fork_asm+0x1a/0x30\n\nFreed by task 135:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3a/0x60\n __kasan_slab_free+0x3f/0x50\n kfree+0x137/0x370\n flexcop_device_kfree+0x32/0x50\n pci_device_remove+0xa6/0x1d0\n device_release_driver_internal+0xf8/0x210\n pci_stop_bus_device+0x105/0x150\n pci_stop_and_remove_bus_device_locked+0x15/0x30\n remove_store+0xcc/0xe0\n kernfs_fop_write_iter+0x2c3/0x440\n vfs_write+0x871/0xd70\n ksys_write+0xee/0x1c0\n do_syscall_64+0xac/0x280\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the delayed work item is properly canceled and any executing delayed\nwork has finished before the device memory is deallocated.\n\nThis bug was initially identified through static analysis. To reproduce\nand test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced\nartificial delays within the flexcop_pci_irq_check_work() function to\nincrease the likelihood of triggering the bug.(CVE-2025-39996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nIf we add a new entity with id 0 or a duplicated ID, it will be marked\nas UVC_INVALID_ENTITY_ID.\n\nIn a previous attempt commit 3dd075fe8ebb (\u0026quot;media: uvcvideo: Require\nentities to have a non-zero unique ID\u0026quot;), we ignored all the invalid units,\nthis broke a lot of non-compatible cameras. Hopefully we are more lucky\nthis time.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[ 20.830206] usb 1-1: Using ep0 maxpacket: 8\n[ 20.833501] usb 1-1: config 0 descriptor??\n[ 21.038518] usb 1-1: string descriptor 0 read error: -71\n[ 21.038893] usb 1-1: Found UVC 0.00 device \u0026lt;unnamed\u0026gt; (2833:0201)\n[ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[ 21.042218] ------------[ cut here ]------------\n[ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[ 21.043195] Modules linked in:\n[ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[ 21.044639] Workqueue: usb_hub_wq hub_event\n[ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 \u0026lt;0f\u0026gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[ 21.051136] PKRU: 55555554\n[ 21.051331] Call Trace:\n[ 21.051480] \u0026lt;TASK\u0026gt;\n[ 21.051611] ? __warn+0xc4/0x210\n[ 21.051861] ? media_create_pad_link+0x2c4/0x2e0\n[ 21.052252] ? report_bug+0x11b/0x1a0\n[ 21.052540] ? trace_hardirqs_on+0x31/0x40\n[ 21.052901] ? handle_bug+0x3d/0x70\n[ 21.053197] ? exc_invalid_op+0x1a/0x50\n[ 21.053511] ? asm_exc_invalid_op+0x1a/0x20\n[ 21.053924] ? media_create_pad_link+0x91/0x2e0\n[ 21.054364] ? media_create_pad_link+0x2c4/0x2e0\n[ 21.054834] ? media_create_pad_link+0x91/0x2e0\n[ 21.055131] ? _raw_spin_unlock+0x1e/0x40\n[ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210\n[ 21.055837] uvc_mc_register_entities+0x358/0x400\n[ 21.056144] uvc_register_chains+0x1\n---truncated---(CVE-2025-40016)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSquashfs: fix uninit-value in squashfs_get_parent\n\nSyzkaller reports a \u0026quot;KMSAN: uninit-value in squashfs_get_parent\u0026quot; bug.\n\nThis is caused by open_by_handle_at() being called with a file handle\ncontaining an invalid parent inode number. In particular the inode number\nis that of a symbolic link, rather than a directory.\n\nSquashfs_get_parent() gets called with that symbolic link inode, and\naccesses the parent member field.\n\n\tunsigned int parent_ino = squashfs_i(inode)-\u0026gt;parent;\n\nBecause non-directory inodes in Squashfs do not have a parent value, this\nis uninitialised, and this causes an uninitialised value access.\n\nThe fix is to initialise parent with the invalid inode 0, which will cause\nan EINVAL error to be returned.\n\nRegular inodes used to share the parent field with the block_list_start\nfield. This is removed in this commit to enable the parent field to\ncontain the invalid inode number 0.(CVE-2025-40049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix crypto buffers in non-linear memory\n\nThe crypto API, through the scatterlist API, expects input buffers to be\nin linear memory. We handle this with the cifs_sg_set_buf() helper\nthat converts vmalloc\u0026apos;d memory to their corresponding pages.\n\nHowever, when we allocate our aead_request buffer (@creq in\nsmb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly\nputs aead_request-\u0026gt;__ctx in vmalloc area.\n\nAEAD algorithm then uses -\u0026gt;__ctx for its private/internal data and\noperations, and uses sg_set_buf() for such data on a few places.\n\nThis works fine as long as @creq falls into kmalloc zone (small\nrequests) or vmalloc\u0026apos;d memory is still within linear range.\n\nTasks\u0026apos; stacks are vmalloc\u0026apos;d by default (CONFIG_VMAP_STACK=y), so too\nmany tasks will increment the base stacks\u0026apos; addresses to a point where\nvirt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that\nhappens.\n\nIn practice: too many parallel reads and writes on an encrypted mount\nwill trigger this bug.\n\nTo fix this, always alloc @creq with kmalloc() instead.\nAlso drop the @sensitive_size variable/arguments since\nkfree_sensitive() doesn\u0026apos;t need it.\n\nBacktrace:\n\n[ 945.272081] ------------[ cut here ]------------\n[ 945.272774] kernel BUG at include/linux/scatterlist.h:209!\n[ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI\n[ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)\n[ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014\n[ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)\n[ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220\n[ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff \u0026lt;0f\u0026gt; 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b\n[ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246\n[ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030\n[ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070\n[ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000\n[ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070\n[ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010\n[ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000\n[ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0\n[ 945.286683] Call Trace:\n[ 945.286952] \u0026lt;TASK\u0026gt;\n[ 945.287184] ? crypt_message+0x33f/0xad0 [cifs]\n[ 945.287719] crypto_gcm_encrypt+0x36/0xe0\n[ 945.288152] crypt_message+0x54a/0xad0 [cifs]\n[ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs]\n[ 945.289300] smb_send_rqst+0xa3/0x160 [cifs]\n[ 945.289944] cifs_call_async+0x178/0x340 [cifs]\n[ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]\n[ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs]\n[ 945.291759] ? find_held_lock+0x32/0x90\n[ 945.292212] ? netfs_advance_write+0xf2/0x310\n[ 945.292723] netfs_advance_write+0xf2/0x310\n[ 945.293210] netfs_write_folio+0x346/0xcc0\n[ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10\n[ 945.294250] netfs_writepages+0x117/0x460\n[ 945.294724] do_writepages+0xbe/0x170\n[ 945.295152] ? find_held_lock+0x32/0x90\n[ 945.295600] ? kvm_sched_clock_read+0x11/0x20\n[ 945.296103] __writeback_single_inode+0x56/0x4b0\n[ 945.296643] writeback_sb_inodes+0x229/0x550\n[ 945.297140] __writeback_inodes_wb+0x4c/0xe0\n[ 945.297642] wb_writeback+0x2f1/0x3f0\n[ 945.298069] wb_workfn+0x300/0x490\n[ 945.298472] process_one_work+0x1fe/0x590\n[ 945.298949] worker_thread+0x1ce/0x3c0\n[ 945.299397] ? __pfx_worker_thread+0x10/0x10\n[ 945.299900] kthr\n---truncated---(CVE-2025-40052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Disallow dirty tracking if incoherent page walk\n\nDirty page tracking relies on the IOMMU atomically updating the dirty bit\nin the paging-structure entry. For this operation to succeed, the paging-\nstructure memory must be coherent between the IOMMU and the CPU. In\nanother word, if the iommu page walk is incoherent, dirty page tracking\ndoesn\u0026apos;t work.\n\nThe Intel VT-d specification, Section 3.10 \u0026quot;Snoop Behavior\u0026quot; states:\n\n\u0026quot;Remapping hardware encountering the need to atomically update A/EA/D bits\n in a paging-structure entry that is not snooped will result in a non-\n recoverable fault.\u0026quot;\n\nTo prevent an IOMMU from being incorrectly configured for dirty page\ntracking when it is operating in an incoherent mode, mark SSADS as\nsupported only when both ecap_slads and ecap_smpwc are supported.(CVE-2025-40058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix race in do_task() when draining\n\nWhen do_task() exhausts its iteration budget (!ret), it sets the state\nto TASK_STATE_IDLE to reschedule, without a secondary check on the\ncurrent task-\u0026gt;state. This can overwrite the TASK_STATE_DRAINING state\nset by a concurrent call to rxe_cleanup_task() or rxe_disable_task().\n\nWhile state changes are protected by a spinlock, both rxe_cleanup_task()\nand rxe_disable_task() release the lock while waiting for the task to\nfinish draining in the while(!is_done(task)) loop. The race occurs if\ndo_task() hits its iteration limit and acquires the lock in this window.\nThe cleanup logic may then proceed while the task incorrectly\nreschedules itself, leading to a potential use-after-free.\n\nThis bug was introduced during the migration from tasklets to workqueues,\nwhere the special handling for the draining case was lost.\n\nFix this by restoring the original pre-migration behavior. If the state is\nTASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to\nforce a new loop iteration. This allows the task to finish its work, so\nthat a subsequent iteration can reach the switch statement and correctly\ntransition the state to TASK_STATE_DRAINED, stopping the task as intended.(CVE-2025-40061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: start using dst_dev_rcu()\n\nChange icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.\n\nChange ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),\nipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().(CVE-2025-40074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_metrics: use dst_dev_net_rcu()\n\nReplace three dst_dev() with a lockdep enabled helper.(CVE-2025-40075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix mailbox API compatibility by negotiating supported features\n\nThere was backward compatibility in the terms of mailbox API. Various\ndrivers from various OSes supporting 10G adapters from Intel portfolio\ncould easily negotiate mailbox API.\n\nThis convention has been broken since introducing API 1.4.\nCommit 0062e7cc955e (\u0026quot;ixgbevf: add VF IPsec offload code\u0026quot;) added support\nfor IPSec which is specific only for the kernel ixgbe driver. None of the\nrest of the Intel 10G PF/VF drivers supports it. And actually lack of\nsupport was not included in the IPSec implementation - there were no such\ncode paths. No possibility to negotiate support for the feature was\nintroduced along with introduction of the feature itself.\n\nCommit 339f28964147 (\u0026quot;ixgbevf: Add support for new mailbox communication\nbetween PF and VF\u0026quot;) increasing API version to 1.5 did the same - it\nintroduced code supported specifically by the PF ESX driver. It altered API\nversion for the VF driver in the same time not touching the version\ndefined for the PF ixgbe driver. It led to additional discrepancies,\nas the code provided within API 1.6 cannot be supported for Linux ixgbe\ndriver as it causes crashes.\n\nThe issue was noticed some time ago and mitigated by Jake within the commit\nd0725312adf5 (\u0026quot;ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5\u0026quot;).\nAs a result we have regression for IPsec support and after increasing API\nto version 1.6 ixgbevf driver stopped to support ESX MBX.\n\nTo fix this mess add new mailbox op asking PF driver about supported\nfeatures. Basing on a response determine whether to set support for IPSec\nand ESX-specific enhanced mailbox.\n\nNew mailbox op, for compatibility purposes, must be added within new API\nrevision, as API version of OOT PF \u0026amp; VF drivers is already increased to\n1.6 and doesn\u0026apos;t incorporate features negotiate op.\n\nFeatures negotiation mechanism gives possibility to be extended with new\nfeatures when needed in the future.(CVE-2025-40104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping\n\nWhen an invalid value is passed via quirk option, currently\nbytcr_rt5640 driver just ignores and leaves as is, which may lead to\nunepxected results like OOB access.\n\nThis patch adds the sanity check and corrects the input mapping to the\ncertain default value if an invalid value is passed.(CVE-2025-40121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: use RCU in ip6_xmit()\n\nUse RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent\npossible UAF.(CVE-2025-40135)\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().\n\nget_netdev_for_sock() is called during setsockopt(),\nso not under RCU.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dst_dev_rcu().\n\nNote that the only -\u0026gt;ndo_sk_get_lower_dev() user is\nbond_sk_get_lower_dev(), which uses RCU.(CVE-2025-40149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: debugfs: Fix legacy mode page table dump logic\n\nIn legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR\nmaybe uninitialized or zero in that case and may cause oops like:\n\n Oops: general protection fault, probably for non-canonical address\n 0xf00087d3f000f000: 0000 [#1] SMP NOPTI\n CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014\n RIP: 0010:pgtable_walk_level+0x98/0x150\n RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206\n RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e\n RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000\n RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002\n R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000\n R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98\n FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n pgtable_walk_level+0x88/0x150\n domain_translation_struct_show.isra.0+0x2d9/0x300\n dev_domain_translation_struct_show+0x20/0x40\n seq_read_iter+0x12d/0x490\n...\n\nAvoid walking the page table if TT is not 00b or 01b.(CVE-2025-40155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: use RCU in ip6_output()\n\nUse RCU in ip6_output() in order to use dst_dev_rcu() to prevent\npossible UAF.\n\nWe can remove rcu_read_lock()/rcu_read_unlock() pairs\nfrom ip6_finish_output2().(CVE-2025-40158)",
"id": "OESA-2025-2802",
"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-2802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38381"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38584"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38633"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38659"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41079"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42101"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42297"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49925"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49930"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49948"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49957"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49962"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50002"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22026"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22043"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23133"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37822"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38109"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38231"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38361"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38457"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38470"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38566"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38588"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38614"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38636"
},
{
"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-38727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39677"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39825"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39866"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40049"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40074"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40121"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40135"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40139"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40155"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40158"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-38381",
"CVE-2024-38584",
"CVE-2024-38615",
"CVE-2024-38633",
"CVE-2024-38659",
"CVE-2024-38667",
"CVE-2024-40902",
"CVE-2024-40904",
"CVE-2024-41079",
"CVE-2024-42101",
"CVE-2024-42102",
"CVE-2024-42245",
"CVE-2024-42247",
"CVE-2024-42297",
"CVE-2024-49863",
"CVE-2024-49875",
"CVE-2024-49894",
"CVE-2024-49905",
"CVE-2024-49925",
"CVE-2024-49930",
"CVE-2024-49935",
"CVE-2024-49948",
"CVE-2024-49949",
"CVE-2024-49950",
"CVE-2024-49957",
"CVE-2024-49962",
"CVE-2024-50002",
"CVE-2024-50005",
"CVE-2024-53131",
"CVE-2024-57887",
"CVE-2024-57900",
"CVE-2024-58095",
"CVE-2025-21945",
"CVE-2025-21968",
"CVE-2025-22022",
"CVE-2025-22025",
"CVE-2025-22026",
"CVE-2025-22039",
"CVE-2025-22042",
"CVE-2025-22043",
"CVE-2025-23133",
"CVE-2025-37822",
"CVE-2025-37861",
"CVE-2025-37899",
"CVE-2025-37973",
"CVE-2025-37994",
"CVE-2025-37997",
"CVE-2025-38005",
"CVE-2025-38058",
"CVE-2025-38071",
"CVE-2025-38109",
"CVE-2025-38231",
"CVE-2025-38282",
"CVE-2025-38350",
"CVE-2025-38361",
"CVE-2025-38443",
"CVE-2025-38457",
"CVE-2025-38470",
"CVE-2025-38477",
"CVE-2025-38527",
"CVE-2025-38566",
"CVE-2025-38588",
"CVE-2025-38614",
"CVE-2025-38617",
"CVE-2025-38636",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-38727",
"CVE-2025-39675",
"CVE-2025-39677",
"CVE-2025-39684",
"CVE-2025-39697",
"CVE-2025-39810",
"CVE-2025-39817",
"CVE-2025-39825",
"CVE-2025-39866",
"CVE-2025-39881",
"CVE-2025-39911",
"CVE-2025-39947",
"CVE-2025-39994",
"CVE-2025-39996",
"CVE-2025-40016",
"CVE-2025-40049",
"CVE-2025-40052",
"CVE-2025-40058",
"CVE-2025-40061",
"CVE-2025-40074",
"CVE-2025-40075",
"CVE-2025-40104",
"CVE-2025-40121",
"CVE-2025-40135",
"CVE-2025-40139",
"CVE-2025-40149",
"CVE-2025-40155",
"CVE-2025-40158"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.